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FOREWORD 


The  MANPRINT  Division  of  the  U.S.  Army  Research  Institute  for  the 
Behavioral  and  Social  Sciences  (ARI)  conducts  manpower,  personnel,  training, 
and  human  performance  research  associated  with  the  development,  acquisition, 
and  operation  of  Army  systems.  The  MANPRINT  research  described  in  this  report 
evaluates  the  data  collection  component  of  the  Command,  Control,  Communica¬ 
tions,  and  Intelligence  Test-Instrumentation  (C3I2)  System,  a  system  designed 
to  provide  Army  operational  testers  with  the  capability  for  automated  data 
collection  and  analysis  during  field  tests  of  C3I  systems. 

The  evaluation  the  C3I2  data  collection  subsystem  (DCS)  was  conducted  by 
ARI’s  Fort  Hood  Field  Unit  during  the  period  November  1989  to  June  1990.  The 
findings  are  concerned  primarily  with  human  engineering  factors,  but  the  re¬ 
port  also  discusses  manpower,  personnel,  training,  and  system  safety  issues; 
health  hazards  were  not  an  issue  of  concern.  The  research  has  led  to  signifi¬ 
cant  hardware  and  software  modifications  that  have  effectively  increased  the 
operability  of  the  system  and  provided  many  lessons  learned  for  use  in  the 
development  of  the  mature  C3I2. 

This  research  was  part  of  the  Fort  Hood  Field  Unit’s  research  taslc  • 
"Soldier-System  Considerations  in  Force  Development  Testing."  It  was  con¬ 
ducted  in  conjunction  with  the  U.S.  Army  Test  and  Experimentation  Command's 
(TEXCOM)  validation  testing  of  the  prototype  DCS  and  in  accordance  with  the 
provisions  of  a  Memorandum  of  Understanding  between  the  ARI  and  Training  and 
Doctrine  Command  (TRADOC)  Combined  Arms  Test  Activity  (now  TEXCOM)  dated  7  May 
1981. 


Organizations  that  have  received  this  report  include  the  U.S.  Army  Test 
and  Experimentation  Command  (system  proponent,  program  director,  project 
manager,  and  system  tester).  Applied  Research  Laboratories  of  the  University 
of  Texas  at  Austin  (system  developer),  Planning  Research  Corporation  (system 
support  contractor),  and  the  U.S.  Army  Communications  and  Electronics  Command 
(currently,  joint  proponent  with  TEXCOM).  Interim  and  final  results  of  the 
research  were  briefed  to  the  Commander,  HQ,  TEXCOM,  and  to  representatives  of 
the  previously  mentioned  organizations  in  March  and  April  1990. 


EDGAR  M.  JOHNSON 
Technical  Director 
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C3I  INSTRUMENTATION  SYSTEM:  MANPRINT  EVALUATION  OF  THE  DATA  COLLECTION 
SUBSYSTEM 


EXECUTIVE  SUMMARY 


Requirement : 

The  Command,  Control,  Communications,  and  Intelligence  Test-Instru¬ 
mentation  System  (C3I2)  is  a  computerized,  soldier-operated  hardware  system 
being  developed  for  Army  operational  testers.  It  provides  automated  data 
collection  and  near  real-time  data  reduction  during  field  tests  of  C3I  sys¬ 
tems.  Because  one  of  the  two  primary  components  of  C3I2,  the  Data  Collection 
System  (DCS),  was  at  the  prototype  stage  of  development  during  the  period  of 
this  research,  an  opportunity  existed  to  provide  constructive  user  feedback  to 
the  developing  contractor  at  a  time  more  conducive  to  nondisruptive  and  cost- 
effective  system  modification.  The  other  primary  component,  the  Data  Reduc¬ 
tion  System  (DRS),  was  still  in  its  conceptual  stage  and  was  not  evaluated. 

This  research  provides  the  Army  and  the  developing  contractor  with  the 
advantage  of  an  early  initial  evaluation  of  the  emerging  DCS  hardware  and 
software  interfaces  and  related  system  documentation.  The  evaluation  was 
conducted  in  the  context  of  the  Manpower  and  Personnel  Integration  (MANPRINT) 
system  acquisition  concept,  which  comprises  the  domains  of  manpower,  person¬ 
nel,  training,  human  factors  engineering,  system  safety,  and  health  hazards. 
Performed  by  the  U.S.  Army  Research  Institute  for  the  Behavioral  and  Social 
Sciences  (ARI)  MANPRINT  Division,  Fort  Hood  Field  Unit,  the  evaluation  empha¬ 
sized  human  factors,  but  also  dealt  at  some  length  with  the  other  domains, 
except  health  hazards,  which  was  dismissed  as  of  minimal  concern. 


Procedure: 

An  evaluation  office  was  maintained  at  the  developing  contractor’s 
laboratories  from  November  1989  until  May  1990.  During  this  period,  the 
evaluator  underwent  system  familiarization  and  interacted  daily  with 
development  teams. 

Two  operational  field  tests  of  the  DCS  were  conducted  by  the  Army  Test 
and  Experimentation  Command  (at  Fort  Sill,  January  1990,  and  at  Fort  Hood, 
April  1990) .  ARI  was  part  of  the  TEXCOM  test  team  during  both  tests  and  was 
responsible  for  evaluating  MANPRINT-related  test  issues. 

Before  the  first  field  test,  a  detailed  human  factors  evaluation  of  DCS 
hardware  and  software  interfaces  and  operator -maintainer  documentation  was 
conducted.  During  this  time,  positions  on  manpower,  personnel,  and  training 
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issues  were  being  developed  and  discussed  with  the  Army,  the  developing 
contractor,  and  the  system  support  contractor.  The  latter  was  to  provide 
field  engineers,  operators,  and  maintainers  for  the  upcoming  field  tests. 

During  the  field  tests,  the  DCS  was  evaluated  to  determine  the  devel¬ 
oper’s  progress  in  improving  and  correcting  human  factors  engineering 
features.  Previously  unnoted  findings,  including  safety  problems,  were 
documented,  as  were  operator  performance  times  and  operator -maintainer  errors 
and  other  problems  related  to  human  factors  and  training  deficiencies.  Evi¬ 
dence  from  the  field  tests  was  also  used  to  finalize  positions  on  manpower  and 
personnel  issues.  Evaluator  observations  were  documented  as  events  occurred; 
operator -maintainer  expenditure  of  time  was  documented  on  a  minute-by-minute 
basis . 


Findings : 

1.  Manpower  &  personnel.  The  major  finding  was  that  use  of  system 
support  contractor  technicians  as  DCS  operators  is  wasteful  because  their 
maintenance  skills  are  seldom  exploited  at  the  operator’s  position.  The  use 
of  enlisted  military  personnel,  trained  as  operators,  would  free  the  techni¬ 
cian  to  use  nonoperational  skills  more  effectively. 

2.  Training.  No  formal  training  program  had  been  developed  (or 
planned);  hence,  no  formal  training  evaluation  was  conducted.  However, 
noticeable  gaps  in  operator  and  maintainer  knowledge  and  performance  were 
noted  during  the  field  tests.  Manuals  for  operators  and  maintainers  were 
inadequate  as  training  and  reference  documents  and  required  considerable 
augmentation  by  other  instruction.  Altogether,  16  specific  training  findings 
were  documented.  Despite  these  observations,  it  is  noted  that  the  DCS  seemed 
potentially  easy  to  learn  and  operate;  it  will  probably  not  require  extensive 
training  time. 

3.  Human  factors.  These  findings  fall  into  four  categories: 

(a)  DCSlDRS  user  interface  uniformity:  It  was  argued  that,  from  a 
MANPR1NT  perspective,  emulation  of  the  DCS  interface  by  the  DRS  would  be  a 
mistake  because  it  would  mean  incorporating  significant  human  factors  defi¬ 
ciencies  into  the  DRS  for  the  sake  of  an  unnecessary  commonality  of  "look  and 
feel."  It  was  resolved  that  DRS  interface  development  would  be  independent, 
using  lessons  learned  from  the  DCS  effort  only  to  the  extent  that  they  bene¬ 
fited  the  DRS  interface. 

(b)  Performance  times  for  DCS  setup  and  teardown  tasks:  Hard-wire 
setup  under  ideal  conditions  required  1-1/2  hours.  Teardown  required  about  50 
minutes.  Deployment  of  a  new  location  would  require,  at  a  minimum,  2  hours  20 
minutes,  not  including  transit  time,  new  site  location  and  layout,  weather 
delays,  and  so  on.  Much  setup  and  teardown  time  is  consumed  by  tasks  associ¬ 
ated  with  antenna  erection  and  takedown.  All  significant  tasks  involved 
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in  setup  and  teardown  are  listed  in  an  appendix,  along  with  a  minute-by-minute 
task  timeline. 


(c)  DCS  operator-software  interface  deficiencies :  Forty-nine  software 
interface  shortcomings  were  documented,  including  inadequacy  of  the  self-test, 
complexity  of  menus  and  terminology,  absence  of  hard-disk  backup  capability, 
and  software- induced  operator  errors.  Especially  crucial  findings  were  inade¬ 
quate  archiving  process  for  data  in  volatile  memory,  inadequate  system  alerts, 
and  easy  accidental  reinitialization  with  probable  loss  of  data.  The  archiv¬ 
ing  process  has  been  improved,  and  the  alert  and  reinitialization  problems 
have  been  largely  resolved. 

(d)  DCS  operator-hardware  interface  deficiencies:  Thirty-two  hardware 
interface  problems  were  noted.  They  involved  troubleshooting  the  power  gen¬ 
erator,  cumbersome  procedures  for  stowing  equipment,  ceiling  lights  reflecting 
into  operators*  eyes,  location  of  the  printer  and  other  equipment,  and  com¬ 
puter  mounting  procedures. 

4.  Safety.  Three  safety  problems  were  noted.  Most  notable  was  the 
reported  instability  of  the  DCS  vehicle.  The  Army  asked  the  developer  to 
determine  the  vehicle’s  center  of  gravity  and  evaluates  the  danger. 

5.  Health  hazards.  No  health  hazards  were  encountered  or  expected  to 
be  associated  with  C3I2. 


Utilization  of  Findings: 

The  evaluation  of  the  C3I2  DCS  prototype  produced  105  MANPRINT  findings 
and  identified  many  potential  improvements,  not  only  for  the  prototype  itself, 
but  for  its  successors.  Few  of  the  noted  problems  were  major;  most  of  the 
major  problems  have  been  at  least  partially  resolved. 

Taken  separately,  some  of  the  findings  appear  trivial.  In  aggregate, 
however,  they  describe  a  system  with  numerous  "rough  edges"  that  produce  un¬ 
necessary  operator  and  maintainer  error  and  inefficiency.  The  rough  edges 
were  not  expected,  owing  to  the  prototype  status  of  the  system.  Documentation 
of  the  findings  has  already  led  to  many  improvements  and  a  lessened  likelihood 
that  shortcomings  will  be  carried  over  into  the  development  of  the  DRS  and  to 
future  versions  of  the  DCS. 
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C3I  TEST-INSTRUMENTATION  SYSTEM: 

MANPRINT  EVALUATION  OF  THE  DATA  COLLECTION  SUBSYSTEM 


System  Description  and  Development 

The  Command,  Control,  Communications,  and  Intelligence  (C3I)  Test- 
Instrumentation  System  (C3I2)  is  a  computer-based  data  collection  and  analysis 
tool  consisting  of  two  major  components,  the  Data  Collection  System  (DCS)  and 
the  Data  Reduction  System  (DRS).  The  DCS  and  DRS  are  mobile  computer  systems 
currently  housed  in  separate  TEMPEST-certif ied  S-710/M  shelters  mounted  on 
modified  four -wheel-drive  M-880  "pickup"  trucks  with  attached  trailer-mounted 
20  kW  generators.  Their  primary  purpose  is  to  provide  the  capability  for 
automated  real-time  data  collection  and  data  analysis  during  operational 
evaluations  of  Army  Tactical  Command  and  Control  Systems.  C3I2  is  an  automat¬ 
ed  instrumentation  system  capable  of  recording  and  analyzing  command  and 
control  information  flow  at  echelons  from  battalion  to  theatre  Army. 

The  DCS  is  designed  to  record  real-time  digital  and  radio  frequency 
information  from  a  C3I  system-under-test,  such  as  AFATDS,  ASAS ,  EPLRS ,  FAADS , 
MCS ,  MSE,  SINCGARS ,  TACFIRE,  and  others.  The  DRS  will  accept  the  data  col¬ 
lected  by  the  DCS  and  provide  the  test  officer  in  the  field  a  near  real-time 
"quick- look"  analysis  to  evaluate  the  progress  of  the  test.  In  the  prototype 
C3I2  system,  the  DCS  data  is  recorded  on  tape  and  manually  transferred  to  the 
DRS  (which  may  or  may  not  be  collocated)  by  carrier,  where  it  is  copied  and 
analyzed.  Extensive  posttest  data  analyses  must,  however,  be  performed  by  the 
data  analysis  center  of  the  testing  organization  rather  than  by  the  DRS. 

The  DCS  is  the  primary  focus  of  this  report.  The  DRS,  in  a  much  earlier 
stage  of  development,  was  not  available  for  detailed  scrutiny  at  the  time  of 
this  research. 

The  DCS  is  designed  to  collect  both  classified  encrypted  information  and 
unclassified  data  transmitted  in  the  clear.  It  collects  data  in  either  a 
hard-wire  or  radio  frequency  mode  or  in  both  modes  simultaneously.  In  the 
hard-wire  mode,  the  DCS  is  hard-wired  to  the  system-under- test  in  such  a  way 
as  not  to  interfere  with  the  performance  of  that  system  during  the  test. 

The  DCS  shelter  includes,  among  other  miscellaneous  items  and  operator 
interfaces,  the  following  primary  equipment:  an  uninterruptible  power  source; 
a  "ruggedized"  computer  with  video  terminal,  keyboard,  hard  disk,  TK50  tape 
recorder,  and  high-speed  printer;  an  additional  VHS  tape  recorder;  an  eight- 
channel  modem  with  accompanying  eight-oscilloscope  bank  and  eight-speaker 
bank;  a  geostationary  operational  environmental  satellite  receiver;  several 
VRC-12  or  SINCGARS  radios;  a  dual  28-volt  power  supply;  KY-57  communications 
security  devices;  and  a  security  safe. 

C3I2  is  being  developed  by  Applied  Research  Laboratories  of  the  University 
of  Texas  at  Austin,  in  accordance  with  a  required- instrumentation-capability 
document  originally  submitted  in  1985  by  the  Combined  Arms  Test  Activity  (now 
Test  and  Experimentation  Command  [TEXCOM]  of  the  U.S.  Army  Training  and 
Doctrine  Command  [TRADOC]).  The  current  version  of  the  requirements  document 
(22  September  1989)  details  the  basic  system  requirements  as  (a)  the 
capability  of  generating,  tagging,  tracking,  auditing,  and  analyzing  C3I 
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digital  and  analog  messages,  (b)  the  ability  to  stimulate  as  well  as  simulate 
the  system-under- test,  and  (c)  the  ability  to  interoperate  with  current  radios 
and  other  communication  systems. 

The  TRADOC  program  director  and  manager  for  C3I2  is  the  Deputy  Chief  of 
Staff  for  Information,  HQ  TEXCOM.  The  operational  tester  for  the  system  is 
the  Director,  Battlefield  Automation  Test  Directorate,  HQ  TEXCOM.  The  U.S. 
Army  Research  Institute  (ARI),  Fort  Hood  Field  Unit,  conducts  the  manpower  and 
personnel  integration  (MANPRINT)  evaluations  of  the  system  during  operational 
testing  by  TEXCOM. 


Method 

Data  pertaining  to  the  DCS  were  sought  in  the  MANPRINT  domains  of  man¬ 
power,  personnel,  training,  human  factors  engineering,  and  system  safety.  (As 
noted  earlier,  findings  were  most  prevalent  in  the  human  factors  area,  and 
there  appeared  to  be  little  reason  for  concern  in  the  area  of  health  hazards.) 
Data  were  available  from  two  primary  sources:  (a)  in-depth  on-site  DCS 
training  and  detailed  hands-on  experience  with  the  prototype  DCS  over  three - 
and-a-half  months  (November  1989  -  February  1990)  during  its  final  develop¬ 
mental  stages  at  the  University  of  Texas  Applied  Research  Laboratories,  and 
(b)  participation  as  test  team  member  in  two  operational  field  tests  of  the 
DCS  conducted  by  TEXCOM,  the  first  at  the  Fort  Sill  Field  Artillery  Board 
during  the  week  of  28  January  1990,  the  second  at  a  1st  Cavalry  Division  unit 
at  Fort  Hood  the  week  of  16  April  1990.  Throughout  the  period  of  research, 
contact  with  the  individual  members  of  the  DCS  development  team  was  main¬ 
tained,  and  extensive  discussions  of  various  aspects  of  the  software  and 
hardware  development,  as  well  as  system  documentation  and  training,  were 
conducted.  (Additional  limited  findings  pertaining  to  the  DRS  were  developed 
during  the  course  of  this  research  through  communications  with  members  of  the 
developer's  DRS  team  and  the  Army's  project  manager  and  system  tester.) 

The  following  sections  describe  the  two  primary  data  sources. 

On-Site  Laboratory  Observation 

Observations  made  at  the  developer's  laboratory  produced  many  specific 
findings- -particularly  within  the  human  factors  realm,  but  also  within  the 
areas  of  documentation  and  training- -a  number  of  which  were  fed  back  into  the 
development  of  the  system  prior  to  the  government  acceptance  testing  by 
TEXCOM.  Both  software  and  hardware  interface  with  operator  and  maintainer 
were  scrutinized  for  shortcomings  and  characteristics  that  would  tend  to 
contribute  negatively  to  system  operation  or  operator  training  or  that  would 
bear  upon  personnel  (operator  and  maintainer)  selection  factors.  System 
documentation  for  operators  and  maintainers,  which  was  also  in  development, 
was  evaluated,  with  some  suggested  improvements  incorporated  by  the  developer 
prior  to  Army  testing  of  the  system.  Significant  problems  were  tracked 
throughout  the  three-month  period  prior  to  testing  and  noted  as  they  appeared 
or  reappeared  during  testing. 
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Field  Observation 


Initial  Validation  Test 

The  purpose  of  the  DCS  test  at  Fort  Sill  was  to  attempt  to  qualify  the 
system  for  participation,  as  data  collection  instrumentation,  in  an  upcoming 
operational  test  of  the  Single -Channel  Ground/Airborne  Radio  System 
(SINCGARS).  Data  obtained  by  TEXCOM  from  performance  of  C3I2  during  the 
SINCGARS  test  would  be  used  to  determine  the  feasibility  of  using  the  C3I2 
system  in  future  operational  testing  of  C3I  systems. 

(The  SINCGARS  test,  an  initial  operational  test  and  evaluation  of  the 
integrated  communications  security  model  of  the  radio,  was  scheduled  for  the 
April  -  June  1990  time  frame.  Use  of  the  DCS  in  that  test  would  constitute 
the  first  field  trial  of  the  prototype  DCS  in  a  real  operational  situation. 
During  that  test,  TACFIRE  messages  would  be  transmitted  over  the  SINCGARS 
radio  and  recorded  by  the  DCS  using  both  hard-wire  and  radio  receivers.) 

During  the  Fort  Sill  validation  test,  two  prototype  DCS  units  were 
exercr'sed  by  the  TACFIRE  system  (to  which  they  were  hard-wired)  located  at  the 
Artillery  Board.  Two  contractor  operators  were  assigned  to  each  DCS,  but 
actual  operations  were  carried  out  by  one  operator  at  a  time,  the  other  acting 
as  backup.  A  system  engineer  (system  support  contractor)  was  also  on  site  to 
assist  as  needed,  as  were  representatives  of  the  system  developer.  ARI 
provided  one  MANPRINT  evaluator  who  continually  observed  system  operation  and 
maintenance  throughout  the  test  and  documented  significant  incidents,  includ¬ 
ing  operator  and  maintainer  error  and  other  phenomena  as  they  occurred. 

Revalidation  Test 

The  DCS  failed  the  Fort  Sill  test  because  of  a  crucial  software  bug  and 
three  crucial  MANPRINT  findings.  The  latter  were:  (a)  it  was  too  easy  for 
the  operator  to  reinitialize  the  system  inadvertently;  (b)  the  presentation  of 
system  alerts  to  the  operator  was  inadequate;  and  (c)  there  was  a  possible 
safety  hazard  associated  with  vehicle  instability.  (These  findings  will  be 
discussed  in  greater  detail  in  the  presentation  of  findings  that  follows.) 
Consequently,  the  system  was  returned  to  the  developer  for  necessary  modifica¬ 
tions  and  then  retested  with  TACFIRE  at  Fort  Hood  approximately  two  months 
later . 

During  the  DCS  validation  retest  at  Fort  Hood,  tracking  of  human  factors, 
notation  of  operational  and  maintenance  errors,  and  documentation  of  other 
MANPRINT  concerns  was  continued.  In  addition,  it  was  possible  to  measure  the 
overall  duration  of  setup  and  teardown  activities  as  well  as  the  time  required 
for  most  of  the  subtasks  involved. 

Most  of  the  findings  presented  below,  other  than  setup  and  operational 
task  times,  were  observed  prior  to  the  Fort  Hood  revalidation  test,  although 
several  new  findings  surfaced  during  that  test.  Problems  known  to  have  been 
corrected  or  ameliorated  by  the  developer,  the  system  support  contractor,  or 
the  Army  are  noted. 
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Findings 


As  with  other  systems,  the  MANPRINT  findings  associated  with  C3I2  are 
sometimes  difficult  to  pigeon-hole  with  respect  to  the  six  general  MANPRINT 
domains  because  of  their  simultaneous  impact  on  more  than  one  area.  Human 
factors  engineering  considerations,  in  particular,  frequently  have  broad,  and 
often-unforeseen,  implications  for  the  other  areas.  Nevertheless,  each  of  the 
findings  presented  is  listed  under  the  MANPRINT  domain  to  which  it  seemed  most 
pertinent,  except  that  manpower  and  personnel  findings  are  combined  into  one 
section.  Findings  were  obtained  in  the  first  five  areas;  no  problems  were 
detected  in  the  sixth  area,  health  hazards.  Each  finding  is  numbered  for 
reference  purposes. 


Section  1:  Manpower  &  Personnel 


1.1  Operator  Selection 

FINDING:  The  DCS  is  currently  operated  by  system  support  contractor 
technicians.  These  technicians  receive  training  that  goes  substantially 
beyond  that  required  to  operate  the  system,  including  training  in  installation 
procedures,  basic  maintenance,  and  software  management.  Yet,  problems  of  more 
than  routine  significance  that  occur  in  the  field  during  normal  operations  are 
not  addressed  by  the  technicians,  but  by  supervisory  engineering  personnel  of 
the  developing  contractor  and  the  system  support  contractor. 

Impact:  The  technician's  time  is  largely  wasted  at  the  operator's  terminal. 

The  use  of  contracted  technicians  as  opposed  to  enlisted  military  personnel  as 
system  operators  does  not  appear  to  be  necessary  strictly  from  the  standpoint 
of  skill  requirements. 

Comment:  According  to  the  TRADOC  Required  Instrumentation  Capability  document 
for  C3I2,  the  DCS  shall  be  capable  of  sustained  operations  of  up  to  22  hours 
out  of  each  24 -hour  period  of  the  operational  test  of  a  C3I  system,  with  the 
remaining  two  hours  available  for  peripheral  activities  such  as  set  up, 
calibration,  and  checkout.  Additionally,  the  DCS  must  be  able  to  record  90 
percent  of  the  data  flow  from  the  system-under-test.  Hence,  DCS  problems 
encountered  during  field  operations  must  be  solved  hastily.  Meeting  this 
requirement  frequently  requires  rapid  access  to  personnel  with  extensive 
knowledge  of  system  hardware  and  software- -knowledge  that  the  technician  may 
not  be  trained  to  provide  even  though  technician  training  goes  beyond  that 
required  of  an  operator.  Consequently,  the  best  division  of  labor  may  be  to 
employ  enlisted  military  personnel  trained  specifically  for  operating  the 
system  while  using  the  contracted  technician  and  engineering  personnel  in  the 
maintenance  support  function.  This  solution  would  free  up  the  technicians, 
whose  potential  mainte  iance  skills  seem  to  be  largely  wasted  in  their  current 
role  as  system  operators.  A  maintenance  team  composed  of  the  technicians  and 
headed  by  the  hardware  and  software  experts  would  then  be  available  to  move 
from  site  to  site  as  required  to  provide  a  rapid  response  to  maintenance 
needs . 

1.2  Source  of  System  Trainers 

FINDING:  The  C3I2  required- instrumentation-capability  document  contains 

an  apparent  contradiction  regarding  organizational  responsibility  for  furnish¬ 
ing  C3I2  instructors;  that  is,  whether  they  will  be  provided  by  the  developer 
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or  by  an  independent,  system  support  contractor.  The  latter  is  the  Army's 
intention. 


Impact:  Persons  not  knowledgeable  about  the  Army's  intent  may  be  confused  by 

the  document. 

Comment:  The  confusion  stems  from  page  8  of  the  requirements  document: 
Paragraphs  10b(l)  &  (2)  imply  that  the  developer  will  provide  training  only  to 
subsequent  trainers  who  will  be  supplied  by  an  independent  system  support 
contractor;  the  next  paragraph,  accordingly,  specifically  states  that  subse¬ 
quent  training  will  be  the  responsibility  of  the  system  support  contractor. 
Paragraph  (4),  on  the  other  hand,  seems  to  reverse  matters,  stating  that  the 
developer,  not  the  system  support  contractor,  will  provide  system  instructors. 
The  next  revision  of  the  document  should  make  it  clear  that  the  system  support 
contractor  will  provide  instructors  after  the  initial  training  of  cadre  by  the 
developer . 


Section  2:  Training 

2 . 1  Undeveloped  Training  Program 

FINDING:  No  formal  C3I2  training  package  has  been  developed.  Con¬ 
sequently,  it  was  not  feasible  to  conduct  a  formal  training  evaluation. 
However,  the  system  developer,  as  a  matter  of  course,  provided  training  and 
system  documentation  materials  to  the  system  support  contractor  and  other  key 
personnel  in  preparation  for  the  DCS  validation  test.  It  was  possible, 
therefore,  to  take  note  of  several  significant  gaps  in  operator-maintainer 
knowledge  and  performance  during  the  DCS  test  and  in  existing  system  documen¬ 
tation.  Those  observations  are  described  below  (Finding  2.4).  Outside  of  the 
exceptions  noted,  the  operator-maintainers  appeared  to  possess  an  adequate 
understanding  of  system  functioning;  they  were  able  to  accomplish  useful  data 
collection  in  a  manner  consistent  with  the  mission,  except  during  hardware  and 
software  incidences,  most  of  which  were  largely  unrelated  to  MANPRINT 
concerns . 

Impact:  Operators  and  maintainers  may  not  be  able  to  take  full  advantage  of 

the  system's  capabilities  and  documentation  to  perform  with  maximal  effective¬ 
ness  or  solve  operational  and  maintenance  problems  efficiently. 

Comment:  Once  decisions  regarding  manpower  and  personnel  requirements  have 

been  made,  it  would  seem  advisable  to  provide  formalized  C3I2  training, 
including  complete  reference  and  training  manuals,  programs  of  instruction, 
lessons  plans,  and  training  aids,  all  aimed  at  appropriate  target  audiences 
(system  operators,  maintainers,  and  software  and  hardware  engineers). 

Training  on  the  C3I2  system  should  be  formal  and  systematic. 

2.2  Operator  and  Maintainer  Manuals 

FINDING:  There  appeared  to  be  minimal  interest  among  principal  proponents 
of  C3I2  (the  Army,  the  developer,  and  the  system  support  contractor)  in  the 
production  of  high  quality  operator  and  maintenance  documentation. 

Impact:  The  user's  manual  provided  by  the  developer- -Software  User's  Manual 

for  the  TEXCOM  Prototype  Instrumentation  System  (DCS)  (8431501/M0001 ,  14  Nov 
89) --was  not  adequate  to  stand  by  itself  as  a  complete  training  and  reference 
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manual  either  for  operators  or  maintainers.  Its  shortcomings  will  have  to  be 
compensated  for  by  instruction  and  user  experience. 

Comment:  The  lack  of  interest  in  user  documentation  development  is  attributed 
to  several  factors: 

(a)  The  Army  is  requiring  the  developer  to  provide  lesson  plans,  agendas, 
training  aids,  and  instructors,  but  only  for  training  initial  training  cadre, 
(supplied  by  an  independent  system  support  contractor)  who  will  be  responsible 
for  training  future  operators  and  maintainers.  Consequently,  the  developer 
does  not  view  documentation  development  as  a  priority  in  C3I2  development. 

(b)  The  system  support  contractor  envisions  occupying  the  role  of  "system 
operator"  as  well  as  "system  technician/maintainer"  well  into  the  future. 
Consequently,  in  their  view,  there  will  be  a  continuity  of  personnel  of  high 
caliber  who  will  have  minimal  need  for  supportive  documentation,  especially 
for  purposes  of  operator  training.  Most  training  would  be  "on-the-job." 

(c)  Traditionally,  system  documentation  takes  a  back  seat  among  the  various 
priorities  in  the  system  acquisition  process.  Normally,  hardware  concerns 
predominate  during  most  of  system  development;  but  then  acquisition  milestones 
become  urgent,  and  operator's  and  maintainer's  manuals,  which,  of  necessity, 
must  be  among  the  last  system  components  to  be  finalized  (though  not,  of 
necessity,  the  last  to  be  initiated),  tend  to  be  rushed  and  inadequately 
realized. 

(d)  The  developer  did  not  have  personnel  whose  primary  mission  (or  interest) 
was  documentation  development  as  opposed  to  software  and  hardware  develop¬ 
ment-  -a  situation  apparently  not  uncommon  among  system  developers.  Responsi¬ 
bility  for  C3I2  documentation  was  primarily  assigned  to  programmers  whose  main 
interest  lay,  naturally,  in  writing  code,  not  documents. 

The  current  system  employment  documents  for  the  DCS  make  little  distinction 
between  the  operator  user  and  the  maintainer  user.  Probably  this  fact  results 
from  the  anticipation  that  the  operator  and  maintainer  will  be  one  and  the 
same  person.  Finding  1.1,  however,  suggests  that  it  may  be  beneficial  to 
divide  these  responsibilities- - in  which  case  it  would  be  advisable  to  create 
separate  documentation  for  operators  and  system  technicians  and  maintainers. 
If,  indeed,  the  system  support  contractor  will  continue  to  be  the  operator  as 
well  as  supervisor  and  maintainer,  then  the  requirement  for  system  employment 
documentation  in  general  is  minimized,  though  not  obviated.  If  TEXCOM  or 
others  will  supply  system  operators,  then  the  need  for  a  high  quality 
operator's  manual  becomes  greater  because  the  system  support  contractor  will 
have  greater  technical  knowledge  and  longer  association  with  the  system  than 
military  supplied  operators.  (There  is  an  additional  developer's  document, 

C3I  Instrumentation  Data  Collection  System  Hardware  Deployment  Training  Manual 
[GE-EM-89-5,  8431501/M001 ,  14  Nov  89]  that  has  not  been  evaluated.  It 
probably  needs  to  be  combined  with  the  software  user's  document  cited  above.) 

Considerations  similar  to  those  presented  in  the  discussion  of  this  finding 
also  need  to  be  applied  to  the  prototype  DRS  and  to  all  subsequent  C3I2 
systems.  Documentation  requirements  and  documentation  standards  for  subse¬ 
quent  versions  should  be  considered  now  while  the  system  is  still  in  its 
relatively  early  stage  of  development.  Because  the  future  versions  will  be 
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significantly  more  complex  than  the  prototype,  questions  relating  to  operator 
personnel  selection  and  documentation  become  more  significant  factors. 

2.3  Training  Time 

FINDING:  From  informal  observations  of  the  training  provided  to  the 
system  support  contractor  by  the  developing  contractor,  the  prototype  DCS 
appears  to  be  relatively  easy  to  learn  and  operate. 

Impact:  It  is  estimated  that  an  effective  training  package  would  require  less 

than  a  week  to  train  a  system  operator  educated  at  the  high  school  level  to 
perform  DCS  physical  setup  and  operational  tasks. 

Comment:  Trained  tasks  would  include  those  peripheral  tasks  necessary  to 
operate  the  DCS  and  support  an  operational  test  of  a  C3I  system:  site 
selection;  vehicle  preventive  maintenance,  checks,  and  service;  hard-wire 
deployment,  and  so  on;  but  not  DCS  system  software  management  (software 
installation  &  modification,  disk  formatting,  etc.)  or  other  than  routine 
system  adjustment,  repair,  and  maintenance.  For  these  additional  tasks, 
additional  technical  personnel  would  be  required.  Also,  given  less  than  one 
week  of  training,  it  would  not  be  possible  to  include  other  than  rudimentary 
training  on  the  installation  and  operation  of  the  SINCGARS  radio  and  associat¬ 
ed  equipment  that  may  be  present,  such  as  the  KY-57;  however,  minimal  training 
on  these  subsystems  may  be  quite  sufficient  for  the  purposes  of  C3I2. 

2. 4  Specific  Training  Deficiencies :  Gaps  in  Operator  and  Maintainer  Knowl¬ 
edge  and  Performance 

Several  performance  and  knowledge  deficiencies  were  documented  during  the 
validation  and  revalidation  tests.  Because  of  such  deficiencies,  the  DCS 
operator  may  not  be  able  to  take  full  advantage  of  the  system's  capabilities 
and  documentation  to  solve  operational  problems  efficiently.  The  solution 
lies  in  better  training  (see  comment  at  Finding  2.1).  Specific  deficiencies 
are  described  in  the  following  paragraphs . 

2.4(1)  Training  of  operational  details. 

FINDING:  The  training  left  to  the  students  the  task  of  learning  by  trial 

and  error  many  of  the  fine  points  of  the  operational  procedures. 

Impact:  Operators  may  not  learn  efficient  operational  procedures  or  how  to 
respond  to  certain  unusual  or  unanticipated  conditions.  For  example,  during 
the  revalidation  test,  it  was  discovered  that  the  operators  disagreed  about 
whether  or  not  the  TACFIRE  DEVICE  ID  needed  to  be  entered  as  a  capital  letter 
during  a  required  channel  configuration  procedure.  One  operator  had  been 
using  capitals  unnecessarily- -a  small  matter,  undoubtedly,  but  one  of  many 
factors  related  to  the  streamlining  of  operations.  In  another,  more  signifi¬ 
cant  instance  (see  Finding  2.4[7]),  when  the  operators  lost  power  to  the 
shelter  and  tried  to  check  breaker  switches,  they  did  not  know  which  switches 
controlled  which  circuits,  which  caused  a  significant  time  delay  before 
operations  could  be  resumed.  The  switches  had  not  been  labeled  (a  human 
factors  deficiency),  and  the  training  had  made  no  mention  of  them. 

Comment:  A  well-developed  and  administered  training  package  would  help  to 
solve  the  problem. 
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2.4(2)  Procedural  changes. 

FINDING:  Certain  system  changes  introduced  by  the  developer  during  the 

period  between  the  initial  validation  test  and  the  subsequent  revalidation 
test  were  not  adequately  communicated  to  the  operators. 

Impact:  Operators  experienced  confusion;  they  were  likely  to  experience  setup 
or  operational  delays  when  the  system  did  not  perform  as  expected  because  of 
software  or  hardware  changes.  For  example,  on  the  first  day  of  the  revalida¬ 
tion  test,  the  operators  were  puzzled  about  the  procedure  for  configuring  new 
channels,  since  a  "NEW"  option,  previously  available,  had  been  removed  from 
the  list  of  primary  options  (see  Finding  3.4[3]).  Another  example  was  the 
addition  of  a  new  tape  recorder  with  no  operational  instructions. 

Comment:  Such  problems  are  difficult  to  counteract  with  systems  in  a  state  of 

evolution,  such  as  C3I2.  Nevertheless,  greater  official  emphasis  on  operator 
and  maintainer  training  would  help  to  alleviate  the  difficulties. 

2.4(3)  Electrical  grounding  of  DCS  shelter. 

FINDING:  While  the  system  documentation  describes  normal  grounding 
procedures  ("pound  the  ground  stake  into  the  earth  about  2  feet"),  no  discus¬ 
sion  of  alternative  methods  is  provided.  Also,  as  is  true  with  many  other 
systems ,  no  method  is  provided  for  the  operator  to  determine  that  a  proper 
ground  has  been  achieved. 

Impact:  In  locations  where  it  is  not  feasible  to  drive  a  grounding  rod  two 

feet  into  the  ground,  the  likelihood  of  achieving  a  proper  ground  may  be 
diminished. 

Comment:  System  documentation  should  provide  adequate  discussion  of  grounding 

procedures  for  all  operational  situations  that  may  be  encountered  (e.g., 
parking  lot  locations).  To  the  extent  that  grounding  of  the  system  is 
important,  it  should  be  stressed  in  training.  And,  ideally,  there  should  be  a 
method  for  determining  the  adequacy  of  the  ground  once  it  is  installed. 

2.4(4)  Geostationary  Operational  Environmental  Satellite  (GOES)  antenna 
operation . 

FINDING:  During  the  revalidation  test,  one  operator  concluded  that 

something  was  wrong  with  the  GOES  antenna  equipment  because  he  had  waited 
"over  5  minutes"  for  satellite  lock-up  without  success.  Consequently,  he 
readjusted  the  angle  of  the  antenna,  replaced  the  antenna  cable,  checked  the 
antenna  connection,  and  manipulated  the  GOES  receiver  panel  controls.  Ten 
minutes  later  the  GOES  receiver  began  to  display  the  proper  time.  The  system 
developer  said  that  the  problem  may  have  been  simply  the  "impatience"  of  the 
operator  and  that  it  normally  takes  the  GOES  receiver  about  five  minutes  to 
lock-up  with  the  satellite. 

Impact:  If  not  waiting  long  enough  for  the  receiver  to  accomplish  satellite 
lock-up  was  the  essence  of  the  problem,  then  approximately  10  minutes  was 
wasted  making  unnecessary  corrections  to  the  system  because  of  the  lack  of 
sufficient  procedural  training. 
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Comment:  The  amount  of  time  an  operator  should  wait  for  lock-up  should  be 
established  as  an  operational  prescription,  and  training  should  include  the 
information.  The  problem  was  not  operator  "impatience,"  but  rather  the  lack 
of  specific  instructions  on  how  long  one  should  wait. 

2.4(5)  "Boot-up"  procedures . 

FINDING:  An  operator  asked  whether  during  boot-up  an  incorrect  time  entry 
could  be  corrected  without  starting  the  initialization  over  from  the  begin¬ 
ning.  He  believed  it  was  impossible,  which  was  true.  He  was  unaware, 
however,  that  the  correctness  of  the  time  entry  is  unimportant  at  this  point. 
According  to  the  developer,  any  time  can  be  entered  with  no  effect  on  the  data 
collection  system,  since  the  latter  uses  GOES  time. 

Impact:  The  operator  reported  that  he  had  been  rebooting  the  system  to 

correct  erroneous  time  entries--a  significant  waste  of  time. 

Comment:  If  the  correct  time  is  neither  necessary  nor  useful  to  the  system, 

it  should  not  be  required  of  the  operator  in  the  first  place  (a  human  factors 
problem).  Because  the  system  does,  however,  require  the  entry,  operators 
should  be  informed  in  their  training  and  in  associated  documentation  that 
entry  of  the  correct  time  is  unnecessary. 

2.4(6)  TK50  data  archiving. 

FINDING:  During  the  validation  test,  one  or  more  of  the  operators  could 

not  provide  self -satisfactory  answers  to  the  following  questions:  (a)  How 
would  the  system  respond  should  an  imminent  condition  of  "tape  full"  arise? 
That  is,  would  the  system  provide  an  alert?  (b)  What  happens  when  the  tape  is 
removed  and  replaced  with  another?  That  is,  does  hard  disk  archiving  continue 
where  it  left  off  with  the  previous  tape  or  go  all  the  way  back  to  the 
beginning  to  archive  all  the  data  again?  (c)  What  is  the  correct  procedure 
for  switching  tapes  during  data  collection?  (d)  What  happens  when  the 
operator  tries  to  shut  down  the  system  with  normal  shutdown  procedures  before 
all  data  have  been  archived?  One  operator  was  of  the  opinion  that  normal 
shutdown  procedures  could  be  concluded  before  all  data  were  archived  and  that, 
as  a  consequence,  unarchived  data  on  the  hard  disk  would  be  lost.  The 
operator  could  not  find  information  pertaining  to  this  question  in  the 
documentation  available  to  him  after  searching  for  approximately  three 
minutes . 

Impact:  Incomplete  or  erroneous  knowledge  of  the  data  archiving  process  could 
lead  to  mistakes  in  data  collection,  data  handling,  troubleshooting,  and 
problem  solving  procedures;  and  although  the  system  guards  against  loss  of 
data,  the  operator  may  be  led  to  perform  operations  conducive  to  data  loss  and 
inefficient  or  ineffective  operations. 

Comment:  Complete  knowledge  of  the  data  archiving  process  is  essential  to 

efficient,  sustained  operations  without  loss  of  data  or  operational  effi¬ 
ciency.  Additional  training  needs  to  be  provided  in  this  area,  and  documenta¬ 
tion  should  be  complete  and  easily  referenced. 
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2.4(7)  Circuit  breaker  panel  switches. 

FINDING:  An  operator  who  was  questioned  about  this  panel  was  not  familiar 
with  the  function  of  any  of  the  switches.  It  is  presumed  that  none  of  the 
operators  had  been  trained  in  this  subject  (see  also  Finding  2.4[1]). 

Impact:  Operator  inability  to  use  the  panel  effectively. 

Comment:  Ensure  that  all  equipment  that  must  be  understood  and  used  by 

operators  is  included  in  operator  training  and  system  documentation. 

2.4(8)  Modem  LEDs  and  labels.  (See  also  Finding  3.5[23] .) 

FINDING:  None  of  the  system  operators  (/maintainers)  knew  the  meaning  of 

each  row  of  indictor  lights  (light  emitting  diodes)  on  the  modem  panel.  The 
eight  rows  have  the  following  unexplained  labels:  TD,  RD,  DCD,  CTS ,  RTS,  DTR, 
DSR ,  and  RI . 

Impact:  The  labels  are  so  cryptic  as  to  be  useless  to  the  person  who  has  not 
committed  their  meanings  to  memory.  The  operators  knew  the  meaning  of  the 
first  four  rows  of  lights  (although  not  the  translation  of  all  of  their 
labels),  but  had  only  sketchy  knowledge  of  the  others.  They  constitute  an 
operational  and  troubleshooting  handicap. 

Comment:  All  signals  and  labels  should  provide  useful  information  to  the 

operator;  they  should  be  fully  explained  and  understood.  Otherwise,  they 
should  be  disabled  and  removed  if  feasible. 

2.4(9)  Computer  panel  display-control  toggle  switches.  (See  also 
Finding  3 . 5 [ 30] . ) 

FINDING:  At  least  one  of  the  operators  was  unfamiliar  with  the  functions 
of  the  three  toggle  switches  on  the  upper  right-hand  corner  of  the  computer's 
front  panel.  Not  all  of  these  switches  were  functional  in  the  DCS. 

Impact:  Operators  may  be  unaware  of  the  ability  to  switch  the  contents  of  the 
panel  display. 

Comment:  These  controls,  as  well  as  all  others  with  which  the  operator  should 
be  familiar,  should  be  illustrated,  described,  and  discussed  in  system 
documentation;  and  their  operation  should  be  covered  in  training. 

2.  '(10)  Computer  access  door.  (See  also  Finding  3.5[28].) 

FINDING:  The  operators  were  not  given  guidance  regarding  the  tightening 
of  the  computer  door  screws,  nor  when,  exactly,  the  door  must  be  closed  for 
security  reasons.  During  the  validation  test,  the  door  was  frequently  left 
open  during  operations. 

Impact:  Possible  breach  of  security. 

Comment:  Appropriate  guidance  should  be  provided  in  training,  and  the 
doctrine  should  be  clearly  detailed  in  system  documentation.  The  operator 
needs  to  know  the  answers  to  questions  such  as,  Is  the  shelter  secure- - 
regardless  of  whether  the  computer  access  door  is  closed- -if  the  shelter  door 
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is  closed?  If  appropriate,  the  inside  of  the  computer  access  door  (exposed 
when  the  door  is  open)  should  have  a  caution  or  warning  label. 

2.4(11)  Power  generator . 

FINDING:  The  engine  fuel  mixtures  began  to  run  rich  several  days  into  the 
validation  test  (see  Finding  3.5[1]).  The  operators  were  unaware  of  the  cause 
of  and  solution  to  the  problem. 

Impact:  Possible  loss  of  reliable  power. 

Comment:  Operators  and  maintainers  should  be  trained  to  avoid  the  problem  by 

taking  appropriate  maintenance  actions.  The  problem  and  its  solution  should 
be  noted  in  system  documentation. 

2  A (12)  "ORIGIN"  &  "SENDER"  (RUNTIME  SYSTEM  screen). 

FINDING:  One  operator  reported  that  the  distinction  between  these  two 

concepts  had  not  been  made  during  training.  He  did  not  know  the  difference. 

Impact:  Degradation  of  operational  effectiveness. 

Comment:  The  meaning  of  all  software  interface  items  should  be  made  clear, 
both  in  training  and  in  documentation. 

2.4(13)  Operator  checklist . 

FINDING:  There  is  no  current  listing  of  important  tasks  that  should  be 

performed  during  normal  operations. 

Impact:  Some  operators  may  forget  to  perform  certain  tasks  that,  while 

perhaps  not  critical  to  operations  under  many  circumstances,  could  lead  to 
serious  consequences  in  unusual  circumstances. 

Comment:  Place  a  short  list  of  important  reminders  on  the  inside  of  the 
shelter  door.  The  list  should  be  located  as  high  as  possible  on  the  door  so 
that  it  will  be  noticed  by  operators  entering  the  shelter.  The  list  should 
include  topics  such  as  grounding  requirements  (ground  rod  depth,  etc.),  the 
requirement  to  have  circuit  breaker  13  in  the  off  position  prior  to  starting 
the  generator,  the  advisability  of  operating  with  the  computer  panel  lock  in 
the  locked  position,  and  so  on. 

Section  3:  Human  Factors 

3.1  User  Interface  Uniformity  Between  the  Data  Collection  System  &  the  Data 
Reduction  System 

FINDING:  The  developer  originally  intended  to  pattern  the  DRS  user 
interface  closely  after  that  of  the  DCS.  However,  in  light  of  the  MANPRINT 
findings  associated  with  the  DCS  (herein  described) ,  they  began  to  question 
whether  that  approach  should  be  followed.  The  arguments  summarized  in  the 
comment  section  below  were  presented  to  the  Army  and  the  developer,  and, 
consequently,  a  decision  was  made  against  emulation. 
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Impact:  In  emulating  the  prior  developed  DCS,  the  DRS  would  have  a  consistent 

and  familiar  "look  and  feel."  However,  such  conformity  would  be  achieved  at 
the  cost  of  having  to  incorporate  known  MANPRINT  deficiencies  of  the  DCS  into 
the  DRS . 

Comment:  Ideally,  the  DCS  and  DRS  (as  components  of  a  single  system)  would 

have  the  same  "look  and  feel."  However,  when  one  component  (here,  the  DCS)  is 
developed  in  advance  of  the  other,  the  question  arises,  Should  Che  subsequent 
component  incorporate  "lessons  learned"  during  the  initial  development  if 
doing  so  tends  to  make  the  user  interfaces  dissimilar ? 

Other  considerations  aside,  the  superficial  aspects  of  the  different  compo¬ 
nents  of  a  system  should  be  designed  to  accommodate  user's  needs  as  students, 
operators,  and  maintainers  of  the  system.  Variables  involved  in  design-for- 
user  considerations  include  three  that  are  particularly  relevant  to  the 
present  concern:  (a)  transfer  of  training  (including  negative  transfer)  from 
system  component  to  system  component;  (b)  retention  of  skill  and  knowledge 
levels  over  periods  during  which  the  system  is  not  used;  and  (c)  ease  of 
learning,  operating,  and  maintaining  the  system.  They  are  discussed  in  turn: 

(a)  Transfer  of  training.  Upon  rare  occasion,  the  unusual  requirements  of  an 
upcoming  Army  operational  test,  may  create  a  need  for  the  operator  of  one  C3I2 
system  component  to  cross  train  on  the  other.  Normally,  however,  the  DCS 
operator  will  not  be  a  DRS  operator,  and  the  DRS  operator  will  not  be  a  DCS 
operator.  Once  the  operational  test  is  underway,  the  operator  of  one  subsys¬ 
tem  will  not  have  to  cross  over  to  the  other,  because  robbing  one  system 
component  to  fill  a  void  in  another  would  normally  be  an  unsatisfactory  solu¬ 
tion;  backup  operators  (including  maintenance  personnel,  if  necessary)  will  be 
available  for  both  the  DCS  and  DRS.  (In  an  emergency,  DCS  operations  would 
have  to  take  priority.) 

Positive  transfer  would  be  desired  if  an  operator  needed  to  switch  between 
different,  complex  system  components;  but  that  is  not  the  case  with  C3I2. 
Hence,  the  need  for  positive  transfer  of  training  is,  here,  at  a  minimum. 

Furthermore,  owing  to  the  absence  of  complex  operational  requirements  and  the 
ample  allotment  of  time  in  which  to  accomplish  operational  tasks  in  the  C3I2 
system,  negative  transfer  of  training  between  components  should  not  be  of 
great  concern  regardless  of  interface  characteristics.  Negative  transfer 
would,  nevertheless,  tend  to  be  minimized  to  the  extent  that  the  DCS  and  DRS 
interfaces  were  different. 

So,  under  most  foreseeable  circumstances,  the  DCS  and  DRS  operators  will  be 
different  persons;  and  if,  upon  occasion,  they  were  the  same,  neither  positive 
nor  negative  transfer  would  be  of  great  concern. 

(b)  Skill  and  knowledge  retention.  It  is  expected  that  both  DCS  and  DRS 
operators  (and,  to  some  extent,  maintainers)  will  experience  significantly 
long  periods  of  C3I2  inactivity  during  hiatuses  between  operational  tests  and 
that,  consequently,  there  will  be  prolonged  periods  of  little  or  no  practice 
operating  (or  maintaining)  the  system.  The  system  support  contractor  has 
noted,  however,  that  their  standard  procedure  is  to  exercise  skills  on  a 
regular  basis.  Thus,  if  the  Army  supplies  system  operators  while  the  system 
support  contractor  supplies  maintainers  (as  recommended),  the  retention  of 


12 


performance  and  knowledge  levels  may  be  more  problematical  for  operators  than 
for  maintainers . 

Retention  will  be  directly  correlated  with  the  operational  simplicity  of  the 
system.  It  is  important,  therefore,  that  both  the  DCS  and  DRS  be  designed  for 
simplicity- -especially  the  follow-on  versions,  which  hold  the  promise  of  being 
considerably  more  complex  than  the  prototypes.  The  prototype  DCS  interface  is 
to  a  great  extent  complete  at  this  time.  But  basic  operations  are  suffi¬ 
ciently  easy  despite  a  considerable  number  of  human  engineering  rough  edges . 
The  prototype  DRS,  incompletely  developed  at  the  time  of  this  report,  may  be 
somewhat  more  difficult  to  operate.  Thus,  while  DRS  is  still  in  an  early 
stage  of  development,  it  is  an  opportune  time  to  ensure  that  its  user  inter¬ 
face  is  effective  and  conducive  to  the  easy  retention  of  operating  knowledge 
and  skill . 

(c)  Maintainers  and  the  operator  interface.  The  maintainer  may  have  to  be 
familiar  with  both  systems  and  may,  therefore,  require  a  passing  knowledge  of 
both  DCS  and  DRS  operators'  jobs,  but  will  not  be  required  to  be  skilled  in 
operations.  Consequently,  operator  interface  considerations  are  not  of  major 
importance  to  the  maintainer  either  for  the  DCS  or  the  DRS  or  for  the  relation 
between  them. 

All  things  considered,  there  appears  to  be  little  reason  to  take  into  account 
the  interface  design  of  the  DCS  in  the  design  of  the  DRS,  except  insofar  as 
shortcomings  of  the  former  can  be  avoided.  Lessons  learned  from  the  DCS 
development  effort  should  be  referenced  by  the  DRS  developers  without  regard 
for  a  need  to  emulate  the  DCS.  If  anything,  operation  of  the  DRS  should  be 
made  distinct  from  that  of  the  DCS,  which  would  be  of  benefit  to  the  few  users 
who  may  be  required  to  operate  or  maintain  both  systems.  The  DRS  interface 
designer  should  concentrate  on  making  the  interface  easy  to  learn,  easy  to 
operate,  and  easy  to  remember.  An  attempt  to  make  the  interface  characteris¬ 
tics  of  the  two  system  components  alike  can  only  be  to  the  detriment  of  the 
DRS,  its  users,  and  the  C3I2  system  as  a  whole.  Finally,  future  versions  of 
the  DCS  could  benefit  from  lessons  learned  from  the  independent  development  of 
the  DRS . 

3.2  System  Setup  Time 

DCS  setup  performance  times  were  recorded  on  three  days  during  the 
revalidation  test,  which  employed  the  same  operators  as  the  original  valida¬ 
tion  test.  Hence,  the  operators  were  experienced,  which  lends  credence  to  the 
time  data  as  representative  of  moderately  seasoned  operators. 

Setup  started  at  approximately  0800  hrs  with  the  "buttoned-up"  DCS  vehicle 
and  attached  trailer  already  in  place  at  a  predetermined  trailer  location. 
Weather  and  other  physical  site  conditions  were  ideal.  Two  operators  were 
present.  Setup  included  the  following  major  activities: 

1.  Detaching  generator  trailer  from  shelter  vehicle,  and  associated 
tasks . 

2.  Positioning  shelter  vehicle,  opening  shelter,  unpacking  equipment,  and 
associated  tasks. 
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3.  Deploying  four  antennas  (receive/transmit,  receiver-only,  GOES,  & 
test-coordination  antennas),  and  associated  tasks. 

4.  Booting-up  computer,  configuring  DCS  software,  printing  hard  copy  of 
configuration  information,  and  associated  tasks. 

5.  Hard-wire  layout  to  five  TACFIRE  vehicles  located  within  approximately 
100  feet,  and  associated  tasks. 

FINDING:  On  Day  1,  only  start  and  stop  times  were  recorded.  Complete 
setup,  including  hard-wire  layout,  required  1  hr  35  min.  On  Day  2,  the  times 
to  accomplish  major  steps  in  the  setup  procedures  were  recorded.  Table  1 
shows  the  setup  timeline  for  the  second  test  day.  Note  that  cumulative  time 
through  achievement  of  data  collection  capability  was  1  hr  18  min.  The 
remaining  time  required  to  complete  hard-wiring  into  the  host  system  (here , 
TACFIRE)  would  be  expected  to  be  variable  from  system  to  system  and  situation 
to  situation.  Complete  setup  including  the  hard-wiring  required  1  hr  45  min. 


Table  1 

Timeline  for  major  setup  tasks:  Revalidation  test,  day  2 
Elapsed 

time  (min) _ Operator  activity _ 

000  Start  setup. 

060  DCS  software  program  started. 

078  Computer  prepared  to  collect  data  ("runtime 

system"  up) . 

105  Last  of  5  hard-wire  connections  to  TACFIRE 

completed. 


Table  2,  slightly  more  detailed,  shows  the  setup  timeline  for  Day  3.  Complete 
setup,  including  wire  layout  required  1  hr  33  min.  Time  to  data  collection 
capability  was  52  min. 


Table  2 


Timeline  for  major  setup  tasks:  Revalidation  test,  dav  3 
Elapsed 

time  (min) _ Operator  activity _ 

000  Start  setup. 

009  Computer  turned  on. 

031  Computer  self  test  completed;  DCS  software 

started. 

052  DCS  channel  configuration  started  and  completed; 

computer  ready  to  collect  data. 

093  Last  of  5  hard-wire  connections  to  TACFIRE 

completed. 
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(A  greatly  expanded  version  of  Table  2  is  provided  in  the  appendix.  The  value 
of  the  expanded  table  lies  both  in  its  detailed  description  of  the  nature  of 
the  DCS  setup  tasks  and  its  potential  for  use  in  analyzing  time  requirements 
for  significant  setup  subtasks  and  the  development  of  critical  task 
information. ) 

Impact:  The  requirement  of  an  hour  and  a  half  for  hard-wire  setup  under  the 
most  ideal  of  conditions  (good  weather;  flat,  unencumbered  terrain;  short 
distances,  stationary  system-under- test)  complicates  considerably  the  task  of 
making  hard-wire  connections  to  a  mobile  system-under- test .  Additional  DCSs 
may  have  to  be  deployed  to  anticipated  locations  in  advance  of  the  system- 
under-test  to  allow  sufficient  time  for  data  collection  preparations.  (Set 
also  Finding  3.3.)  Once  site  location  and  preparation  are  completed,  the  DCS 
can,  under  ideal  conditions,  be  prepared  to  collect  radio  traffic  in  approxi¬ 
mately  one  hour. 

Comment:  Examination  of  the  expanded  table  in  the  appendix  shows  that  one  of 

the  largest  consumers  of  setup  time  is  antenna  deployment.  One  operator 
worked  alone  for  approximately  30  minutes  on  nothing  but  antenna  deployment 
tasks.  Both  operators  worked  together  for  another  26  minutes  only  on  antenna 
deployment  tasks.  Thus,  the  total  clock  time  required  for  deployment  of 
antennas  was  56  minutes;  while  the  total  number  of  man  minutes  was  82.  Since 
the  number  of  man  minutes  required  for  all  tasks  necessary  for  data  collection 
capability  (by  radio)  was  approximately  180,  antenna  deployment  tasks  consumed 
about  45%  of  the  time  required  for  data  collection  preparation.  It  stands  to 
reason  that  a  more  easily  deployed  antenna  system  (e.g.,  hydraulic,  pneumatic, 
or  both)  could  substantially  reduce  the  amount  of  time  required  for  setup. 

(See  also  Finding  3.3,  Comment.) 

3.3  System  Teardown  Time 

The  time  required  to  teardown  the  two  primary  antennas  (receive/transmit  & 
receive-only  antennas),  including  the  time  to  stow  all  related  equipment 
(masts,  guy  lines,  stakes,  etc.)  was  recorded  on  the  second  day  of  the  revali¬ 
dation  test.  On  the  third  day,  a  detailed  record  of  all  teardown  procedures 
was  kept.  The  procedures  were,  of  course,  essentially  the  reverse  of  the 
setup  procedures  and  included  the  following  major  tasks: 

1.  Exit  data  collection  software;  conduct  computer  shutdown  procedures; 
complete  end-of-shift  bookkeeping. 

2.  Stow  and  secure  all  loose  equipment  inside  the  shelter,  including 
monitor,  keyboard,  and  operator  chairs. 

3.  Take  down  and  stow  antennas,  guy  lines,  and  related  equipment. 

4.  Disconnect,  spool,  and  stow  field  wire  from  system-under- test . 

5.  Disconnect  and  spool  power  and  generator  control  cables. 

6.  Connect  generator  trailer  to  vehicle.  Conduct  final  cleanup  and  stow 
any  remaining  items  in  preparation  for  transit. 

FINDING:  Teardown  of  the  receive/transmit  and  receive-only  antennas  on 

Day  2  required  23  minutes.  Table  3  shows  the  major  tasks  involved  in  teardown 
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and  the  associated  cumulative  timeline  established  on  Day  3.  Note  that 
teardown  was  less  time  consuming  than  setup,  as  would  be  expected.  (A  much 
expanded  version  of  Table  3  is  found  in  the  appendix.  Like  the  expanded 
version  of  Table  2  for  setup  procedures,  the  expanded  teardown  table  is  useful 
for  examining  procedural  details.) 


Table  3 


Elapsed 
time  (min) 

Operator  Activitv 

000 

Start  teardown;  begin  computer 

shutdown . 

002 

Computer  off. 

007 

Shelter  equipment  stowed  and  secured  for  transit. 

024 

Antennas  down  and  stowed. 

039 

All  field  wire  in  and  wound. 

043 

Power  cables  stowed. 

046 

Trailer  connected  to  vehicle. 

049 

All  equipment  stowed;  teardown 

complete . 

Impact:  Despite  the  shorter  duration  of  teardown  activities,  the  amount  of 

time  required  is  significant,  especially  when  the  purpose  of  the  teardown  is 
to  allow  movement  to  a  new  location  in  response  to  movement  of  the  system- 
under-  test.  The  amount  of  time  required  to  teardown  at  one  location  and  setup 
at  another  location  (not  including  transit  time  and  site  location  and  layout) 
would,  according  to  the  present  data,  be  approximately  2  hrs  20  min  under 
ideal  conditions.  Transit  time  and  other  variables  (e.g.,  weather)  could  add 
substantial  amounts  of  time. 

Comment:  During  teardown,  the  taking  in  of  field  wire  and  antennas  were  the 

major  time  consumers  (see  expanded  teardown  table  in  the  appendix).  Automatic 
antenna  systems  (as  mentioned  in  Finding  3.2)  would  save  much  time.  Addition¬ 
ally,  consideration  might  be  given  to  the  notion  of  abandoning  the  field  wire 
temporarily  (to  be  recovered  later,  perhaps  by  another  crew). 

3.4  DCS  Operator-Software  Interface  Deficiencies 

Although  the  prototype  DCS  software  interface  as  a  whole  is  not  complex, 
it  is  somewhat  inelegant  in  most  of  its  features,  and  some  procedures  are  more 
complicated  than  necessary.  The  CRT  screens  often  include  unnecessary  items 
and  verbiage,  but  they  normally  lead  the  operator  through  steps  in  a  manner 
that  minimizes  error  even  though  certain  important  errors  can  and  do  occur. 
(Specific  examples  of  interface  findings  are  presented  below.)  As  a  conse¬ 
quence  of  the  "roughness"  of  the  software  interface,  inexperienced  students  of 
the  system  and  new  operators  or  maintainers  may  experience  some  confusion  in 
learning  and  some  time  delays  in  operating  the  system.  Experienced  operators 
may  overcome  most  of  the  learning  hurdles,  given  sufficient  time,  though  not 
all  of  the  time  delays,  some  of  which  are  "hard-wired"  into  the  system.  In 
general,  learning  and  performance  decrements  should  not  be  of  great  import  for 
the  prototype  DCS  or  DRS,  but  they  promise  to  be  of  greater  concern  for 
follow-on  versions  now  in  development,  especially  the  DRS. 


16 


3 .4(1)  System  start-up  procedure. 

FINDING:  The  procedure  required  unnecessary  participation  by  the  opera¬ 
tor.  The  console  first  conducted  an  automatic  self  test  and  then  presented 
the  operator  the  message  "VT  320  OK."  Here,  the  operator  had  to  remember  to 
press  <Retum>,  followed  by  b  (for  "boot"),  and  <Retum>  again.  The  monitor 
then  prompted  for  entry  of  the  date  and  time,  after  which  a  series  of  messages 
that  were  not  meaningful  to  the  operator  scrolled  by,  ending  with  "System 
logged  out,"  a  message  that  could  easily  be  misunderstood.  Then  the  operator 
had  to  press  <Retum>  again  to  receive  the  messages  "Welcome  to  Micro  VMS 
2.4.6"  and  "Username:"  Here,  the  operator  typed  in  the  enigmatic  term 
"exedir"  (see  Finding  3.4[30.7])  followed  by  <Retum> .  At  this  point  a  TK50 
tape  had  to  be  in  the  tape  drive  to  allow  subsequent  data  collection. 

("Exedir"  has  since  been  replaced  with  a  more  meaningful  term.) 

Impact:  The  new  operator  or  student  may  be  confused  by  the  requirement  to 

memorize  unnecessary  responses,  view  enigmatic  messages,  and  wait  during  blank 
screens  without  feedback  indicating  whether  or  not  machine  processing  is 
progressing  in  a  normal  manner. 

Comment:  The  start-up  procedures  should  be  revised  in  a  manner  similar  to  the 

following:  The  first  message  "VT  320  OK"  should  be  expanded  to  something  like 

"Console  OK.  Press  return  key  twice  to  boot  system."  (The  two  presses  of  the 
return  key  would  allow  the  system  supervisor  or  technician  with  knowledge  of 
the  appropriate  command  to  intervene  between  .  .  urns  for  maintenance  or 
troubleshooting  operations.  Other  method  for  accomplishing  the  same  effect 
could  be  devised.)  The  screen  should  then  display  a  time  filler  (to  indicate 
that  boot-up  is  taking  place)  until  the  date- time  prompt  appears.  When  the 
date  and  time  have  been  entered  (without  having  to  type  in  punctuation 
delimiters) ,  the  screen  should  return  a  message  like  "Please  ensure  that  the 
TK50  tape  is  inserted  in  the  tape  drive  if  you  wish  data  to  be  archived  during 
data  collection.  Press  <Retum>  to  continue  or  <F1 4>  ('EXIT')  to  quit."  Upon 
pressing  <Return> ,  the  main  menu  should  appear. 

3.U(2)  Validation  of  system  functioning . 

FINDING:  There  is  no  efficient,  non- intrusive  way  for  the  operator  to 
verify  that  the  system  is  responding  normally  to  an  inactive  external  data 
environment . 

Impact:  If  no  "traffic"  has  been  observed  for  a  time,  the  operator  may  wonder 

if  the  system  is  working  properly  and  be  unable  to  make  a  conclusive  test 
without  interfering  with  ongoing  data  collection.  (The  impact  of  this  problem 
would  be  expected  to  be  minimal  during  a  DCS  test  because  of  the  communication 
channels  established  for  test  control.  The  DCS  operator  is  made  aware  of  when 
and  when  not  to  expect  data  transmission.  During  a  normal  deployment  of  C3I2, 
however,  such  communication  channels  can  be  expected  to  be  considerably  less 
dependable  or,  possibly,  absent.) 

Comment:  Certain  system  features  can  provide  relevant  information  to  the 

operator:  (a)  The  channel  oscilloscopes  might  help  the  well -trained  operator 

who  can  associate  particular  waveforms  with  particular  emitters;  (b)  f’ert 
queues  provided  at  the  display  reveal  certain  local  DCS  problems;  (c)  an 
internal,  hard-wired  self -test  loop  indicates  whether  the  DCS  hardware  is 
functioning  appropriately,  but  would  interfere  with  ongoing  data  collection 
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activities.  Some  sort  of  non- intrusive ,  periodic  means  of  system  self- 
examination  (for  real-time  as  well  as  posttest  analysis)  would  be  useful  and 
should  be  considered  in  future  development  efforts. 

3.4(3)  Removal  of  "NEW"  from  the  data  collection  start-up  options. 

FINDING:  During  the  DCS  validation  test,  the  initial  menu  allowed  the 

operator  to  choose  between  resuming  (RESUME)  a  previous  data  collection 
operation  or  starting  anew  (NEW).  The  NEW  option  was  removed  prior  to  the 
revalidation. 

Impact:  The  advantage  of  this  change  is  that  the  operator  is  prevented  from 
accidentally  choosing  the  NEW  option,  which  reinitializes  the  system,  erasing 
information  from  the  previous  session,  including  configuration  information, 
alerts,  information  messages,  and  data  collection  summary  data.  At  a  minimum, 
this  would  cause  an  inconvenient  time  delay  while  the  operator  reconfigured 
the  system.  However,  several  disadvantages  also  accrue: 

(a)  The  operator  cannot  begin  data  collection  with  a  clean  slate,  so  to  speak. 
The  configuration  parameters  can  be  revised,  but  certain  information,  such  as 
screen  clocks  and  message  rates  remain  intact  whether  or  not  they  are  desired. 
They  cannot  be  revised  through  normal  operational  procedures.  The  operators 
complained  about  the  loss  of  the  NEW  option  and  the  consequences:  "I  don't 
like  that  [expletive  deleted]  'resume.'" 

(b)  The  RUNTIME  SYSTEM  screen  has  a  column  (CHN)  for  channel  numbers  on  the 
right-hand  side  that  is  supposed  to  indicate  which  of  the  channels  are  active 
during  a  given  data  collection  session.  After  removal  of  the  NEW  option,  this 
indicator  appeared  to  act  in  a  cumulative  fashion:  For  example,  if  the 
previous  session  had  had  eight  channels  active  and  the  current  session  had 
five  of  those  eight  active,  the  indicator  would  continue  to  show  eight  chan¬ 
nels  active.  The  usefulness  of  the  CHN  column  is  much  reduced.  (See  also 
Finding  3. 4 [23]  .  ) 

(c)  In  order  to  keep  track  of  message  counts  and  hours  of  operation,  the 
operator  must  remember  to  make  a  note  of  the  initial  readings  immediately 
after  initiating  the  runtime  system.  If  the  message  environment  is  active 
when  the  data  collection  is  started,  and  the  operator  fails  to  take  immediate 
note  of  the  information,  it  cannot  be  subsequently  obtained. 

(d)  The  average  messages  per  hour  readout  is  meaningless  at  first  and  becomes 
accurate  only  after  the  first  hour  of  operation.  This  anomaly  occurs  because 
the  first  hour's  information  is  based  on  data  collection  activity  in  a 
previous  session  rather  than  on  the  current  session. 

Comment:  From  an  operational  standpoint,  a  better  way  to  solve  the  accidental 

reinitialization  problem  would  be  to  allow  the  NEW  option,  but  to  include  with 
it  a  strong  warning  to  the  operator  that  information  from  the  previous  session 
will  be  lost.  The  operator  should  then  be  forced  to  perform  a  key  sequence 
that  would  make  accidental  selection  of  the  NEW  option  highly  unlikely. 
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3.4(4)  Accidental  exit  from  "Runtime  System”  (the  F5  key).  (See  also  Finding 
3.4(31.1].) 

FINDING:  During  a  human  factors  evaluation  of  the  operator's  keyboard 
interface,  conducted  during  the  revalidation  test,  it  was  discovered  that 
pressing  the  F5  function  key  during  the  data  collection  process  caused  an 
immediate  halt  of  the  data  collection  software  and  the  presentation  of  the 
underlying  system  prompt  "»>." 

Impact:  Data  collection  was  in  grave  danger  of  accidental  termination  at  all 

times.  Fortunately,  no  data  were  lost  during  the  test  because  of  this 
deficiency. 

Comment:  Loss  of  data  collection  capability  during  an  operational  test  is  a 

serious  problem.  The  haphazard  or  accidental  pressing  of  the  terminal  keys 
(as  might  occur  if  the  operator  leaned  on  the  keyboard  or  rested  a  clipboard 
on  it)  should  not  be  able  to  terminate  data  collection  operations. 

3.4(5)  Channel  configuration. 

FINDING:  The  operator  cannot  configure  an  additional  channel,  once  data 

collection  has  begun.  The  data  collection  software  program  must  be  exited  and 
rerun . 

Impact:  In  an  active  data  environment,  reinitializing  the  runtime  system 

would  cause  all  incoming  data  to  be  lost  during  reconfiguration. 

Comment:  Ideally,  the  system  should  allow  such  revision  of  the  configuration 

during  data  collection  without  interruption  of  the  data  collection  process. 

3.4(6)  Channel  configuration  feedback. 

FINDING:  In  the  version  of  the  software  examined  prior  to  the  validation 

test,  when  the  last  parameter  was  entered  for  a  channel  during  "channel  param¬ 
eterization,"  the  system  "beeped,"  apparently  to  indicate  that  there  were  no 
more  parameters  to  enter  for  that  channel. 

Impact:  The  beep  would  be  confusing  to  many  new  users,  since  it  would  often 

be  interpreted  as  signaling  an  error  (the  typical  meaning  of  such  a  signal  on 
a  personal  computer) . 

Comment:  As  proposed,  a  different  indicator  was  provided.  The  operator  now 

receives  a  message  on  the  screen  rather  than  the  beep.  The  beep  sounds  only 
if  the  operator  attempts  to  continue  beyond  the  end  of  the  process;  that  is, 
it  now  appropriately  indicates  error. 

3.4(7)  "CHANNEL  SELECTION"  screen. 

FINDING:  Channel  10  appeared  as  "Channel  0." 

Impact:  Operator  confusion. 

Comment:  The  problem  was  reported  to  the  developer  and  subsequently 

corrected . 
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3.4(8)  Tape  dismounting . 

FINDING:  During  the  validation  test  it  was  discovered  that  the  F12 
ARCHIVE  DATA  option  did  not  actually  cause  data  to  be  archived.  Instead,  it 
"prepared"  the  TK50  tape  for  dismount.  Hence  "archive  data"  was  a  misnomer. 
The  label  has  now  been  changed  to  "dismount  tape,"  which  more  closely  reflects 
the  actual  function  of  the  option. 

Impact:  Until  the  labeling  was  changed,  the  operators  were  confused  about  the 
purpose  of  the  option. 

Comment:  While  operator  confusion  has  been  eliminated,  the  system  shortcoming 
that  underlay  the  confusion  still  exists  to  a  degree  (see  Finding  3.4[9]). 

3.4(9)  Data  archiving. 

FINDING:  During  the  validation  test,  a  software  bug  prevented  periodic 
archiving  of  data  either  automatically  or  manually  under  the  particular 
circumstances  of  the  test  (relatively  low  density  traffic) .  The  fault  had 
been  disguised  and  confounded  by  the  mislabeling  of  the  "dismount  tape" 
option,  which  the  operators  initially  thought  provided  them  a  means  of 
manually  archiving  data  at  will  (see  Finding  3.4[8]).  The  problem  was 
partially  remedied  prior  to  the  revalidation  test. 

Impact:  A  hard  disk  failure  prior  to  data  archiving  could  mean  the  loss  of 

test  data.  This  was  a  serious  shortcoming  that  required  fixing. 

Comment:  The  system  will  now  archive  data  at  intervals  dependent  upon  the 

amount  of  data  collection  activity:  The  greater  the  density  of  data,  the  more 
frequently  archiving  occurs.  For  low  density  data  environments,  the  archiving 
intervals  could  still  be  unacceptably  long.  Furthermore,  the  operator  is 
still  not  permitted  to  archive  data  at  will.  A  hard  disk  failure  prior  to 
data  archiving  could  still  mean  the  loss  of  test  data.  The  system  needs  to 
archive  data  automatically  at  regular  intervals  specifiable  by  the  operator  or 
system  supervisor  and  to  allow  discretionary  archiving  by  the  operator. 

3.4(10)  TK50  tape  backup. 

FINDING:  No  means  for  backing  up  the  original  TK50  storage  tapes  is 
provided  at  the  DCS . 

Impact:  With  current  deployment  planning  there  is  a  possibility  (probability 
unknown)  that  collected  test  data  will  be  lost. 

Comment:  During  normal  operations,  data  that  have  been  collected  onto  the 
hard  disk  should  be  automatically  copied  (spooled)  to  the  tape  on  a  regular 
basis  (as  processor  activity  allows).  The  original  data  should  also  remain  on 
the  hard  disk  until  it  becomes  full.  As  currently  designed,  when  the  disk  is 
full,  it  begins  to  overwrite  its  oldest  data,  as  necessary,  to  make  room  for 
new  incoming  data.  If  hard  disk  data  should  become  unretrievable  (for 
whatever  reason) ,  the  TK50  archive  tape  is  the  only  copy  remaining  until  it  is 
transferred  to  the  DRS  and  copied  into  that  system.  Should  the  tape  be 
damaged  prior  to  analysis  at  the  DRS,  required  test  information  may  be 
unattainable.  The  Army  tester  has  decided  that  because  of  redundancies  in 
collected  data  at  different  DCS  sites,  the  probability  of  a  significant  data 
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loss  owing  to  hard  disk  failure  would  not  warrant  including  additional  tape 
backup  hardware  in  the  DCS.  A  formal  assessment  of  this  probability  would 
require  knowledge  of  message  traffic  densities,  how  the  tapes  would  be  handled 
during  a  given  operational  test  of  a  C31  system  (the  amount  of  time  it  will 
take  to  deliver  tapes  to  the  DRS ,  etc.),  and  so  on.  It  would  be  advisable  to 
remember  that  such  a  loss  is  possible,  despite  its  perhaps  low  probability  in 
the  "normal"  test  scenario. 

3.4(22)  Cursor  speed. 

FINDING:  The  cursor  does  not  respond  quickly  enough  to  keep  up  with  a  key 

repeat,  producing  cursor  skid  in  certain  situations- -as  when  the  operator  is 
erasing  a  line  with  a  repeated  backspace  key. 

Impact:  If  a  key  is  repeated  by  holding  it  down,  the  cursor  continues  to  move 

after  the  key  is  released;  making  it  difficult  to  gauge  how  long  to  keep  the 
key  depressed.  The  problem  may  be  only  a  minor  irritation  to  most  operators 
who  notice  it. 

Comment:  According  to  the  developer,  the  trailing  cursor  results  from  slow 

processor  speed,  inherent  in  the  current  system.  The  problem  may  disappear  if 
faster  processors  are  used  in  future  systems. 

3.4(22)  Speed  of  screen  rewrites. 

FINDING:  Screen  changes  are  slow  and  incremental.  Parts  of  some  screens 

are  written  horizontally  (apparently  resulting  from  the  particular  screen 
management  utility  used) . 

Impact:  The  process  of  going  from  one  "mode"  to  another;  conducting  necessary 

start-up,  shutdown,  and  operating  procedures;  accessing  help  and  utility 
screens;  and  so  on,  is  relatively  tedious  compared  with  the  speed  to  which 
today's  computer  users  are  accustomed.  In  a  menu-driven  program  like  this 
one,  the  operator  accomplishes  many  functions  by  moving  in  and  out  of  menus, 
which  makes  the  slow  response  time  especially  noticeable. 

Comment:  The  system  developer  notes  that  the  speed  of  screen  updates 
determined  by  both  the  hardware  and  the  screen  management  utility  and 
currently  unavoidable  for  all  practical  purposes.  As  in  the  previous 
the  solution  may  lie  in  faster  processors. 

3  A (13)  "ABORT  PRINT . " 

FINDING:  Prior  to  the  validation  test,  the  option  ABORT  PRINT  tended  to 

be  confusing,  appearing  at  times  to  be  available  when  it  was  not. 

Impact:  Operator  confusion. 

Comment:  The  developer  corrected  this  "bug"  prior  to  test. 

3.4(24)  "Virtual"  function  keys. 

FINDING:  The  DCS  employs  an  ineffective  operator  interface  technique 
using  so-called  "virtual  function  keys,"  which  are  representations  of  keyboard 
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function  keys  displayed  in  boxes  across  the  bottom  of  the  operator's  monitor. 

Impact:  This  feature,  which  is  in  reality  an  ill-designed  on-screen  menu 
index,  tends  to  slow  down  function  selection  unnecessarily,  wastes  screen 
space  that  could  be  better  devoted  to  other  information  or  blank  space,  and 
may  increase  the  probability  that  the  operator  will  inadvertently  press  an 
incorrect  function  key.  This  menu  index  was  probably  directly  responsible  for 
at  least  two  instances  of  inadvertent  reinitialization  of  the  DCS  front-end 
processors  during  the  validation  test.  The  operators  were  occasionally 
observed  requiring  excessive  amounts  of  time  (on  the  order  of  2  to  4  seconds) 
just  to  determine  which  function  key  to  press  to  select  a  desired  menu  item. 

Comment:  Any  of  a  number  of  other  selection  devices  for  menus  are  available 
that  would  be  a  significant  improvement  over  the  "virtual"  keys.  Keyboard 
keys  should  be  indicated  on  the  screen,  adjacent  to  the  menu  option,  whether 
listed  vertically  or  horizontally.  An  example  of  a  six- item  horizontal  menu 
would  be : 

1  Archive;  2  Clear  Alert;  3  Freeze;  4  Refresh;  5  Setup;  6  Utilities. 

This  example  would  easily  fit  across  one  line  at  the  bottom  of  an  80-column 
screen.  The  cursor  would  default  to  one  of  the  innocuous  options  in  the  menu 
(Freeze  or  Refresh).  The  "virtual"  function  key  feature  should  be  avoided  in 
future  developments .  The  system  developer  has  discontinued  use  of  the  term 
"virtual  function  keys"  (a  term  that  may  be  confusing  to  new  operators),  but, 
in  the  prototype  DCS,  not  the  feature  itself. 

3 .4 (15)  Overemphasis  of  "EXIT"  &  "HELP"  options. 

FINDING:  Most  of  the  screen  menus  include  EXIT  and  HELP  as  basic  menu 

items  that  are  given  equal  status  (emphasis)  with  other  menu  selections  that 
are  much  more  likely  to  represent  the  sought-after  functions. 

Impact:  The  unnecessary  and  repetitive  presentation  of  EXIT  and  HELP  as  basic 
menu  items  tends  to  make  it  more  difficult  for  the  viewer  to  glean  the 
appropriate  information  from  the  menu.  It  also  reduces  the  amount  of 
available  screen  space,  which,  in  turn,  may  necessitate  the  creation  of 
unnecessary  and  conceptually  complicating  sub-menus. 

Comment:  These  two  menu  items  need  to  be  treated  separately  from  the  others. 

A  menu  should  contain  only  those  selections  that  are  major  operational  options 
at  the  time  the  menu  is  displayed.  The  screen  predominance  of  the  EXIT  and 
HELP  items  should  be  minimized  by  relegating  them  to  the  upper  or  lower  screen 
corners,  or  by  other  means. 

3.4(16)  Non-utilization  of  "HELP"  facility. 

FINDING:  The  operators  made  essentially  no  use  of  the  help  screens  during 
either  the  validation  or  revalidation  test. 

Impact:  The  help  facility  is  wasted. 

Comment:  The  initial  version  of  the  help  feature  was  inadequate  because  many 
help  screens  were  missing  and  those  that  existed  provided  little  real  help. 
Prior  to  the  revalidation,  the  developer  enlarged  upon  the  help  facility,  but 
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it  was  still  not  used.  The  later  version  was  not  evaluated,  but  its  disuse 
was  probably  related  to  its  lack  of  salience  and  the  operator's  anticipation 
that  it  would  not  be  helpful. 

3. 4 (1 7)  Mode  selection  "HELP"  screen. 

FINDING:  The  screen  simply  repeats  information  already  provided  by  (or 

easily  deduced  from)  the  MODE  SELECTION  screen  itself.  Part  of  the  wording  is 
awkward:  The  explanation  for  the  menu  item  "CONFIG  CHANS"  is  "Prepare  channel 
parameters  for  use,"  which  indicates  that  the  parameters  are  being  prepared 
for  use,  rather  than  the  channels. 

Impact:  The  content  of  this  help  information  is  of  little  or  no  use.  It 

wastes  time. 

Comment:  In  general,  help  screens  should  not  be  provided  if  the  information 

presented  does  not  give  the  operator  significant  additional  information.  A 
simple  rehashing  of  information  already  at  hand  is  not  useful.  Such  informa¬ 
tion  wastes  time  and  may  be  a  source  of  frustration  to  operators. 

3.4(18)  Self  test. 

FINDING:  This  utility,  still  in  the  design  stage,  is  limited.  A  "bug" 

was  noted  in  the  current  prototype  version. 

Impact:  At  one  point  after  the  Fll  SELF  TEST  option  is  selected,  the  operator 
cannot  abort  the  procedure  even  though  a  menu  providing  that  option  is 
presented. 

Comment:  While,  according  to  the  system  developer,  this  problem  may  continue 

to  exist  in  the  prototype  system,  there  are  plans  to  devote  considerable 
attention  to  further  development  of  the  self-test  utility. 

3.4(19)  "SELF  TEST  UTILITY"  screen. 

FINDING:  In  preparation  for  conducting  the  self  test,  the  operator  is 
forced  to  proceed  through  this  screen,  which  is  essentially  an  unneeded  help 
screen. 

Impact:  Entering  the  self  test  is  more  cumbersome  and  time  consuming  than  it 
need  be  and  gives  the  impression  of  being  more  complicated  than  it  really  is. 

Comment:  Such  screens  should  be  included  in  the  optional  help  facility  rather 

than  as  a  part  of  the  required  operational  sequence. 

3.4(20)  Mis -referencing  of  "RUNTIME  SYSTEM"  screen. 

FINDING:  This  screen  is  referred  to  in  the  operator's  manual  as  a  menu 
screen.  Its  basic  function,  however,  is  to  provide  information  rather  than  to 
provide  options . 

Impact:  The  student  may  be  confused  by  the  fact  that  this  "menu"  is  not  a 
menu . 

Comment:  The  screen  should  be  referred  to  as  a  display  rather  than  a  menu. 


23 


3  A (21)  Runtime  system  clock.  (See  also  Finding  3. 4 [30. 2].) 


FINDING:  During  data  collection,  the  monitor  keeps  track  of  the  amount  of 
time  elapsed  since  the  last  system  initialization.  This  clock  is  labeled 
"TEST  TIME,"  the  meaning  of  which  may  not  be  immediately  apparent  to  the 
student  or  operator,  and  which  is  a  misnomer  if  the  system  has  been  reinitial¬ 
ized  since  the  beginning  of  the  test  (a  likely  event  during  the  validation 
test) . 

Impact:  The  usefulness  of  the  clock  is  diminished. 

Comment:  It  may  be  useful  for  several  reasons  to  allow  the  operator  to  modify 

the  clock  from  the  keyboard:  (a)  The  times  at  various  DCS  sites  could  be 
easily  coordinated  through  time  hacks;  (b)  the  clock  could  be  used  by  the 
operator  to  time  various  test  events;  (c)  the  clock  could  be  reset  to  reflect 
cumulative  times  even  if  the  system  has  been  reinitialized  during  the  test. 
Furthermore,  it  might  be  useful  if  two  such  clocks  were  available  (perhaps 
occupying  the  same  screen  space  via  a  toggle):  One  could  be  used  as  a  timer, 
as  mentioned,  while  the  other  is  cumulating  run  time.  Also,  the  name  of  the 
clock  should  be  changed  (see  Finding  3. 4 [30. 2]). 

3  A (22)  Runtime  system  message  rates. 

FINDING:  "MSG  RATE"  and  "TOTAL  MSG  RATE"  on  the  RUNTIME  SYSTEM  screen  are 

given  with  two  decimal  places. 

Impact:  Unnecessary  precision.  Screen  clutter  (see  also  Finding  3.4[27].) 

Comment:  Show  as  whole  numbers.  One  operator  raised  the  question,  Of  what 

operational  importance  is  the  total  message  rate?  He  could  not  think  of  any 
possible  use  for  the  information.  If  the  information  is  indeed  of  value,  then 
operator  training  and  system  documentation  should  inform  operators  of  its 
purpose  and  importance;  if  not,  it  should  be  removed.  Would  message  rate 
during  operator- specifiable  intervals  be  of  greater  or  additional  value? 

3  A(23)  Runtime  system  active -channel  indicator.  (See  also  Finding  3.4[3], 
Impact  [c] . ) 

FINDING:  The  far  right  column  on  the  screen  presents  a  column  of  channel 

numbers.  The  active  channels  are  highlighted.  The  label  "CHN"  above  this 
column  does  not  indicate  the  purpose  of  the  column. 

Impact:  The  student  must  overcome  the  inadequacy  of  the  column  heading. 

Comment:  Short  of  revising  the  whole  screen,  the  column  heading  could  be 

changed  to  "ACT  CHN,"  meaning  "active  channels"  (with  the  first  abbreviation 
placed  over  the  second  in  the  column  heading) . 

3.4(24)  Presentation  of  alerts. 

FINDING:  During  the  validation  test,  the  "alert"  line  at  the  bottom  of 
the  operator's  screen  continued  to  flash  messages  (some  informational,  others 
bona  fide  alerts)  until  the  operator  manually  canceled  the  message.  New 
messages  overwrote  previous  ones.  The  operators  were  frequently  observed 
operating  for  long  periods  of  time  (e.g.,  all  day)  with  an  uncancelled  message 


flashing.  Alerts  were  not  accompanied  by  audible  signals.  The  method  of 
presenting  system  alerts  to  the  DCS  operator  was  greatly  improved  during  the 
interval  between  the  initial  and  subsequent  validation  tests. 

Impact:  Because  the  operator  was  not  forced  to  act  upon  alert  messages  (such 
as  "TAPE  NOT  MOUNTED,  NOT  MOUNTED  CORRECTLY,  OR  RED  BUTTON  NOT  PRESSED. 

S:  7471700"),  a  message  could  continue  to  flash  indefinitely.  Incoming 
messages,  which  overwrote  the  flashing  message,  could  therefore  have  gone 
unnoticed  and  could  themselves  be  overwritten  by  yet  newer  alerts. 

Comment:  The  method  of  visual  alerts  presentation  is  now  considered  good. 

They  are  presented  very  noticeably  in  the  middle  of  the  monitor  screen,  and 
appropriate  action  is  required.  They  are  still  not  accompanied  by  audible 
signals . 

3. 4(25)  Alert  follow-up . 

FINDING:  Currently,  alerts  are  presented  with  no  prescribed  action 

indicated  for  the  operator.  Many  different  alert  messages  are  possible. 

Impact:  The  operator  may  not  know  what  action  to  take,  if  any,  in  the 

presence  of  some  system  alerts.  The  meaning  of  the  alert  may  not  be  under¬ 
stood. 

Comment:  Each  alert  should  force  the  operator  to  respond  in  some  way  with 

appropriate  available  options. 

3.4(26)  Alert  message  content. 

FINDING:  Many  different  messages  are  possible,  and  some  of  them,  owing  to 
their  technical  content,  may  not  be  understood  by  the  operators.  The  alerts 
are  not  documented. 

Impact:  Without  complete  documentation  of  alerts,  including  their  meaning  and 
prescribed  action,  the  operator  may  not  be  able  to  take  appropriate  action. 

Comment:  Each  alert  message  should  be  accompanied  by  an  identifying  number 
that  can  be  referenced  in  the  operator's  manual.  The  documentation  should 
prescribe  appropriate  operator  action  for  each  message.  Highly  technical 
alerts  could  be  presented  on  the  operator's  display  as  a  reference  number 
only.  No  information  should  be  presented  on  the  display  that  is  not  under¬ 
stood  by  the  operator  (such  as  "S:  7471700"  in  the  message  "TAPE  NOT  MOUNTED, 

NOT  MOUNTED  CORRECTLY,  OR  RED  BUTTON  NOT  PRESSED.  S:  7471700"). 

3.4(27)  Screen  clutter  and  message  reports. 

FINDING:  Some  of  the  screens  are  cluttered  with  unnecessary  verbiage. 

One  example  is  the  "MESSAGE  REPORTS"  screen.  The  operator's  manual  depicts 
the  following: 
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MESSAGE  REPORTS 


MESSAGE  REPORT  PARAMETERS 

ENTER  STARTING  TIME  FOR  REPORT  _  DD-MMM-YYYY  HH:MM:SS 

ENTER  ENDING  TIME  FOR  REPORT  .  DD-MMM-YYYY  HH:MM:SS 

ENTER  CHANNELS  FOR  REPORT  .  ALL 

ENTER  CLASSIFICATION  CODE  (1-4)  . . .  UNCLASSIFIED 

[1 -UNCLASSIFIED,  2-CLASSIFIED,  3-SECRET,  4-TOP  SECRET] 


The  word  "message"  appears  twice.  The  word  "report(s)"  appears  five  times 
(not  including  an  additional  occurrence  on  the  "virtual"  function  key  line  not 
shown  here).  The  word  "enter"  appears  four  times. 

Impact:  Screen  clutter  requires  longer  reading  time  and  causes  the  screen  to 

loose  distinctiveness:  The  intent  of  the  screen  may  be  less  clear;  any 
options  on  the  screen  may  be  less  distinguishable  from  one  another;  and  the 
screen  may  be  less  distinguishable  from  other  screens .  The  net  result  is 
increased  operational  and  training  difficulties. 

Comment:  All  screens  should  be  reviewed  for  unnecessary  clutter  and  revised 
accordingly.  The  example  shown  above  could  be  revised  as  follows: 


MESSAGE  REPORT  DEFINITION 


CURRENT  TIME  IS:  HH:MM:SS 


START  TIME:  DD  MMM  YY  HH  MM  SS 


STOP  TIME:  DD  MMM  YY  HH  MM  SS 


CHANNELS :  ALL  12345678 


CLASSIFICATION  CODE:  UNCLASSIFIED 

CONFIDENTIAL 
SECRET 
TOP  SECRET 


The  cursor  should  jump  to  the  appropriate  positions  for  date  and  time.  Start 
time  should  default  to  the  date  and  time  of  the  first  message  logged  since 
start-up.  Stop  time  should  default  to  the  current  date  and  time.  Channels 


26 


should  default  to  ALL  (other  choices  selected  by  highlighting  with  arrow  key 
and  space  bar  or  return  key) .  Classification  should  default  to  "unclassified" 
(others  chosen  by  highlighting  or  by  toggling  [not  shown]).  Variations  on 
this  general  approach  are,  of  course,  possible.  Note  the  inclusion  of  current 
time  for  operator's  reference. 

3 .4 (28)  "EDIT  WHICH  CHANNELS?"  procedure. 

FINDING:  The  operator  is  unnecessarily  required  to  have  learned  and 
remembered  the  proper  response  format. 

Impact:  This  shortcoming  constitutes  an  easily  avoidable  cognitive  require¬ 
ment  placed  upon  the  student  and  operator. 

Comment:  It  is  unnecessary  (and  inconsistent  with  other  procedures)  to 

require  the  operator  to  generate  a  response  and  a  format  at  this  point.  The 
possible  response  options  could  easily  be  presented  in  a  small  menu  from  which 
the  operator  could  choose  the  appropriate  items. 

3.4(29)  Conceptual  complexity  (menus). 

3 .4(29 . 1)  Unnecessary  categorization  of  options. 

FINDING:  The  opeiai:  jl  interface,  while  simple  enough  in  many  ways,  is  to 
some  extent  unneces'  a'  : Ly  complicated  by  subdividing  primary  options  into  two 
separate  menus .  Thus ,  the  UTILITIES  option  on  the  current  MODE  SELECTION 
screen  calls  for-n  a  sub-menu,  the  UTILITIES  SYSTEM  screen,  containing 
additional  selections  that  could  be  presented  on  the  parent  screen.  Adequate 
room  is  available  on  the  parent  screen,  especially  if  the  "virtual  function 
keys"  were  removed  (as  they  should  be;  see  Finding  3.4[14]). 

Impact:  The  operator's  conceptual  picture  of  the  overall  system  and  the  way 

it  operates  is  made  unnecessarily  complex.  System  operations  may  be  harder  to 
learn,  slower  to  perform,  and  more  prone  to  operator  error  than  necessary. 

Comment:  The  following  is  suggested  as  one  possible  alternative  to  the 
currently  separate  MODE  SELECTION  and  UTILITY  SYSTEM  screens: 
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PRIMARY  OPTIONS 


F6 

Alerts 

F8 

Configure  Channels 

F10 

Begin  Data  Collection 

Fll 

Channel  Statistics  - 

F12 

Configuration  Parameters 

1 

1 

Status  Reports 

F13 

Message  Summary  . 

1 

F1A  EXIT 

F15  HELP 

The  screen  would  appear  with  the  first  alternative,  Alerts,  highlighted;  at 
which  point  the  operator  could  select  Alerts  in  any  of  three  ways:  by 
pressing  the  F6  key,  by  pressing  the  bolded  "a"  key,  or  by  pressing  the  return 
key.  Similarly,  other  menu  items  could  be  chosen  by  pressing  the  associated 
function  key,  the  bolded  letter,  or  by  using  the  arrow  keys  to  highlight  the 
selection  and  then  pressing  the  return  key.  (Particular  items  in  menus  could 
be  grayed  whenever  they  are  temporarily  unavailable  as  choices.) 

The  advisability  of  categorizing  operation  options  and  then  presenting  each 
category  in  a  separate  selection  menu  is  dependent  on  a  number  of  factors, 
among  which  the  following  three  are  especially  relevant  here:  (a)  the 
conceptual  relation  among  the  categories;  (b)  the  amount  of  available  screen 
space;  and  (c)  the  speed  with  which  the  screen  management  software  presents 
the  screens.  If  categories  exhibit  dependencies,  and  screen  space  is  at  a 
premium,  and  speed  is  fast,  then  separate  presentations  tend  to  be  more 
justifiable.  On  the  other  hand,  the  extent  to  which  categories  and  the  items 
within  them  are  parallel,  and  the  greater  the  amount  of  available  screen 
space,  and  the  slower  the  processor,  the  less  the  advantage  in  separate  menus. 

In  the  DCS,  the  primary  operating  options  can  be  considered  parallel  (existing 
dependencies  can  be  shown  on  the  same  screen,  as  for  Status  Reports  shown  in 
the  illustration  above),  screen  rewrites  are  quite  slow,  and  ample  screen 
space  is  available. 

Combining  the  current  MODE  SELECTION  and  UTILITY  SYSTEM  screens  would,  of 
course,  have  ramifications  for  the  design  of  other  related  screens. 

3.4(29.2)  Listing  of  menu  items. 

FINDING:  (a)  In  one  top-level  menu  the  option  items  were  not  listed  in 

logical  sequence.  (b)  Another  instance  in  which  a  menu  item  was  not  a  viable 
option  was  observed. 
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Impact:  (a)  Operators  may  be  led  to  attempt  procedures  in  the  wrong  sequence, 

(b)  Operators  may  experience  confusion  when  trying  to  exploit  unavailable 
options . 

Comment:  Generally,  menu  items  should  be  listed  in  a  logical  sequence  related 
to  efficient  and  orderly  system  operation.  For  example,  selections  that  are 
often  chosen  before  others  may  best  be  placed  at  the  beginning  of  the  menu. 

It  goes  without  saying  that  all  menu  options  should  be  selectable,  unless 
temporarily  suspended  with  appropriate  indication.  Both  noted  instances  were 
corrected  by  the  developer. 

3.4(30)  Conceptual  complexity  (terminology) . 

FINDING:  The  terminology  used  to  name  and  describe  the  operations, 
processes,  menus,  and  other  system  components  is  sometimes  enigmatic,  incon¬ 
sistent,  overused,  easily  confused,  or  easily  forgotten- -especially  for  the 
newcomer.  For  example,  the  terms  "MODE"  (as  in  "MODE  SELECTION")  and  "SYSTEM" 
(as  in  "UTILITY  SYSTEM")  tend  to  complicate  rather  than  simplify  matters 
conceptually  for  the  operator.  Detailed  examples  and  discussions  are  provided 
in  subparagraphs  3.4(30-1)  through  3.4(30-16). 

Impact:  Teaching  system  operations  to  new  students  is  made  more  difficult. 
Student  retention  of  learned  information  is  less  stable.  The  subtle  confu¬ 
sions  that  may  result  from  the  inadvertently  careless  use  of  terminology 
contribute  to  operator  error  and  system  failure. 

Comment:  Persons  who  have  had  a  long-time  relationship  with  a  system  tend  to 

be  insufficiently  appreciative  of  the  extent  to  which  "everything  is  new"  to 
the  naive  observer,  student,  or  operator.  The  terminology  used  to  describe  a 
system  is  an  important  factor  contributing  to  the  ease  of  learning  and 
remembering  system  operations.  The  meaning  of  all  labels,  titles,  and  the 
like,  hat  are  presented  to  a  student  or  operator  should  be  immediately 
apparent;  they  should  not  themselves  constitute  additional  learning  tasks. 
(There  are,  of  course,  situations  in  which  physical  space  or  other  constraints 
require  the  coding  of  information  into  short  or  otherwise  cryptic  forms  that 
must  be  learned  by  operators  before  they  become  useful  guides.)  The  need  to 
learn  and  remember  special  terminology  in  order  to  effectively  operate  a 
system  should  be  minimized.  Simple  alternatives  for  such  terms  can  often  be 
substituted.  (For  example,  "MODE  SELECTION"  and  "UTILITY  SYSTEM"  could  be 
replace  by  alternatives  such  as  "OPTIONS,"  "SELECT  ONE,"  or  the  like.)  A 
conscious  effort  by  hardware,  software,  and  documentation  developers  must  be 
exerted  to  overcome  the  inertia  of  their  experience  in  order  to  create  a  user 
interface  that  will  minimize  learning  problems,  maximize  learning  and  opera¬ 
tional  speed,  and  maximize  the  retention  of  knowledge  and  skills. 

3.4(30.1)  Term:  "System." 

FINDING:  The  term  "system"  is  overused  because  the  developer  tends  to 
present  the  system  (i.e.,  the  C3I2  system)  to  the  operator  and  student  as  a 
collection  of  related  systems  rather  than  as  a  single  system  with  several 
related  functions.  The  term  "system"  appears  in  the  following: 
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•  "C3I2  System" -- Che  system 

•  "Data  Collection  System"  ("DCS”) 

•  "Data  Reduction  System"  ("DRS")--the  DCS  and  DRS  are  two  physi¬ 

cally  and  functionally  separate  system  components  requiring  dif¬ 
ferent  operators 

•  "RUN  SYSTEM" --the  command  to  start  data  collection  within  the  DCS 

•  "RUNTIME  SYSTEM"  and  "Runtime  Subsystem" - -both  used  to  refer  to 

the  DCS  data  collection  function 

•  "UTILITY  SYSTEM"  and  "Utility  Subsystem" - -both  used  to  refer  to  a 

small  collection  of  functions  providing  operational  status 
information 

•  "SYSTEM  QUEUE" --one  of  several  sets  of  notices,  or  "alerts,"  that 

reveal  operational  problems 

•  "Operating  system" - -which,  according  to  the  operator's  manual, 

refers  to  both  "overall  system  operations"  and  the  computer's 
software  "operating  system"  (VMS) 

•  "System  logged  out" --the  boot-up  message  referring,  not  to  the 

C3I2  Data  Collection  system,  but  to  lower  level  software 

Impact:  The  inexperienced  student  operator  may  find  it  difficult  to  conceptu¬ 

alize  the  C3I2  system  (the  manner  in  which  its  components  are  related),  and 
the  resultant  operating  skill  level  may  be  lower  than  necessary.  The  greater 
the  complexity  of  any  system,  or  the  inadequacy  of  the  system-user  interface, 
the  greater  the  tendency  for  some  operators  to  learn  little  more  than  that 
necessary  to  make  the  system  work  at  a  minimal  level. 

Comment:  The  terms  "Data  Collection  System"  and  "Data  Reduction  System"  can 

be  tolerated  because  they  describe  very  discrete  aspects  of  the  overall 
system;  however,  they  would  be  better  described  as  "components,"  "facilities," 
"elements,"  "modules,"  or  the  like,  rather  than  "systems."  Other  simple 
changes  would  also  help  to  clarify  the  conceptual  portrayal  of  the  system. 
Examples:  (a)  The  command  "RUN  SYSTEM"  (an  option  on  the  MODE  SELECTION  menu) 

should  be  something  like  "COLLECT  DATA"  or  "BEGIN  DATA  COLLECTION,"  both  of 
which  more  accurately  reflect  actual  functionality;  (b)  an  alternative  for 
"RUNTIME  SYSTEM"  (the  name  of  the  data  collection  display  screen)  could  be 
"DATA  COLLECTION,"  or  the  like;  (c)  "RUNTIME  SETUP"  could  be  "DATA  COLLECTION 
SETUP";  (d)  "UTILITY  SYSTEM"  could  be  simply  "UTILITIES";  (e)  "SYSTEM  QUEUE" 
could  be  changed  to  "COMPUTER,"  "GENERAL,"  or  some  other  term  that  accurately 
reflects  the  meaning  of  this  alert  category. 

3.4(30.2)  Term:  "TEST  TIME." 

FINDING:  This  heading,  which  appears  on  the  RUNTIME  SYSTEM  screen,  is  not 
necessarily  indicative  of  the  time  shown.  If  the  operator  reinitializes  the 
system,  either  accidentally  or  purposefully,  the  time  will  not  be  cumulative 
from  the  beginning  of  the  test.  (See  also  Finding  3.4[21].) 

Impact:  Interpretation  of  the  time  shown  is  ambiguous. 

Comment:  A  term  like  "CUMfulative ]  RUN  TIME"  would  be  less  confusing  because 
it  would  imply  duration  of  the  current  run. 
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3.4(30.3)  Term:  "Queue. 


FINDING:  This  term,  as  in  "ALERT  QUEUES,”  "SYSTEM  QUEUE,"  "HARDWARE 
QUEUE,"  "SOFTWARE  QUEUE,"  "CHANNEL  QUEUE,"  and  "MISC  QUEUE”  may  be  new  to  some 
student  operators. 

Impact:  It  constitutes  a  small,  nonfunctional  obstacle  that  the  student  may 

have  to  work  around.  It  may  detract  from  understanding  and  does  not  elucidate 
operations.  It  clutters  the  ALERT  QUEUES  menu  screen. 

Comment:  The  term  does  not  significantly  improve  understanding  and  should  be 
dropped.  The  so-called  "alert  queues"  could  be  simply  referred  to  as 
"alerts . " 

3 .4(30 .4)  Term:  "Runtime." 

FINDING:  This  term,  which  appears  in  "RUNTIME  SETUP"  and  "RUNTIME 
SYSTEM,"  is  not  inherently  meaningful. 

Impact:  The  student  operator  must  learn  and  remember  that  its  meaning  is 

simply  "data  collection,"  an  unnecessary  requirement. 

Comment:  The  term  should  be  abandoned  and  replaced  by  "DATA  COLLECTION." 

3.4(30.5)  Term:  "Self  Test  Utility." 

FINDING:  The  self  test  is  not  a  part  of  the  "utility  system,"  as  one 

might  expect  on  the  basis  of  the  terminology. 

Impact:  Additional  confusion  for  the  student  or  operator. 

Comment:  Drop  the  use  of  "utility"  in  connection  with  the  self  test.  Refer 

to  the  self  test  simply  as  the  "self  test." 

3.4(30.6)  Term:  "Mode." 

FINDING:  The  term  is  used  in  "MODE  SELECTION,"  which  refers  to  primary 
operational  options  available  to  the  operator  in  preparing  for  data 
collection. 

Impact:  The  word  "mode"  complicates  the  student's  picture  of  the  system  by 
suggesting  one  must  enter  different  "modes"  of  operation  to  accomplish 
different  objectives. 

Comment:  A  simpler  approach  is  to  treat  the  alternative  menu  items  simply  as 

alternative  choices- -as  shown  in  the  sample  screen  (PRIMARY  OPTIONS)  depicted 
in  Finding  3.4(30.1).  While  it  is  possible  that  the  "mode"  concept  was  useful 
during  system  development,  it  is  not  useful  to  the  operator. 

3.4(30.7)  Term:  "EXEDIR." 

FINDING:  During  training  and  the  validation  test,  operators  had  to  type 

the  esoteric  term  "exedir"  during  start-up  procedures  (see  Finding  3.4[1]). 
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Impact:  Initially,  the  term  was  not  meaningful  to  the  operators;  it  may  have 

remained  so  for  some.  Furthermore,  at  this  point  in  the  procedures,  it  should 
have  been  unnecessary  to  enter  any  command  at  all . 

Comment:  The  term  "exedir"  derives  from  "directory  of  executable  files"  and 
was  handy  for  programmers  involved  in  developing  the  system  software.  It 
should  not  be  required  of  the  operator . 

3. 4(30.8)  Term:  "Top-level." 

FINDING:  This  term,  which  appears  in  the  operator's  manual  to  refer  to 
initial  menu  options,  is  not  a  term  well  known  to  the  layman. 

Impact:  A  learning  obstacle. 

Comment:  Either  define  it  when  first  used  or  replace  it  with  "main,"  "pri¬ 

mary,"  "initial,"  or  the  like. 

3 .4(30.9)  Term:  "DATA  COLLECTION  SYSTEM"  menu. 

FINDING:  This  main  menu,  which  appears  after  the  system  is  booked,  is  not 
well  named.  The  menu  does  not  list  all  primary  components  of  the  so-called 
data  collection  "system."  What  is  more,  the  operator  has,  just  before 
receiving  this  menu,  been  informed  by  the  "system"  that  the  "system"  has 
"logged  out"  (see  Finding  3.4[1]). 

Impact:  The  operator  may  misconstrue  the  meaning  of  the  term  "system"  (see 
Finding  3.4[30.1]). 

Comment:  Retitle  the  menu  "MAIN  MENU." 

3 .4(30 . 10)  Term:  "Front  end  processors." 

FINDING:  This  term,  which  appears  in  screen  menu  items  and  in  the 
operator's  manual  is  not  defined  and  is  not  meaningful  to  computer  illiterate 
persons . 

Impact:  Lack  of  understanding  or  confusion  about  the  purpose  and  functioning 

of  certain  operational  options. 

Comment:  Replace  with  an  innocuous  but  meaningful  term  such  as  "data  collec¬ 
tion  processor"  or  other  appropriate  lay  designation. 

3 .4(30 . 11)  Term:  "PARMS,"  "PARAMS "parameters,"  &  "parameterization." 

FINDING:  The  first  two  both  appear  as  abbreviations  for  "parameters." 

The  terms  are  not  defined. 

Impact:  Some  operators  will  have  to  learn  the  terms  or  follow  instructions 

without  a  clear  understanding  of  their  meaning. 

Comment:  While  "parameter"  is  familiar  enough  to  persons  with  technical  or 
professional  backgrounds,  it  may  be  new  to  the  DCS  operator.  Neither  of  the 
two  abbreviations  is  desirable  if  avoidable;  if  used,  "PARAMS”  is  preferred  to 


32 


"PARMS."  "Parameterization"  should  be  avoided,  as  in  "CHANNEL  PARAMETERIZA¬ 
TION  MENU" --this  menu  appears  in  response  to  selecting  the  "CONFIG  CHANS" 
option  on  the  MODE  SELECTION  menu,  and  could,  therefore,  be  re -entitled 
"CHANNEL  CONFIGURATION  MENU." 

3.4(30.12)  Term :  " SEE  PARMS "  &  " SHOW  PARAMETERS . " 

FINDING:  The  INPUT/EDIT  PARAMETERS  menu  presents  the  option  "SEE  PARMS," 
which  produces  a  screen  entitled  "SHOW  PARAMETERS."  The  terminology  is 
inconsistent,  and  the  word  "show"  is  inappropriate. 

Impact:  Operator  confusion. 

Comment:  "SEE  PARMS"  should  be  "REVIEW  PARAMS"  (if  the  "virtual"  function 

keys  are  retained  on  the  screen) ,  and  "SHOW  PARAMETERS"  should  be  simply 
"PARAMETERS"  or  "CURRENT  PARAMETERS,"  or  the  like. 

3.4(30.13)  Term:  "RESULTS  FROM  TEST  ALL  CHANNELS . " 

FINDING:  This  is  the  title  of  a  screen  that  may  appear  after  the  self 
test  is  conducted.  The  wording  is  awkward. 

Impact:  The  intended  meaning  may  not  be  immediately  apparent  to  the  student 

or  operator. 

Comment:  Better  wordings  would  be:  "RESULTS  FROM  ALL-CHANNEL  TEST," 

"RESULTS:  ALL-CHANNEL  TEST,"  "ALL-CHANNEL  TEST  RESULTS,"  or  the  like. 

3.4(30.14)  Term:  "PREV  SCREEN . " 

FINDING:  This  command  is  unnecessarily  cryptic. 

Impact:  Possible  misunderstanding  as  "preview  screen"  rather  than  "previous 

screen. " 

Comment:  Change  to  "PRIOR  SCREEN." 

3 .4(30 . 15)  Term:  Menu  headings  &  screen  generating  commands. 

FINDING:  Some  of  the  screen  menus  have  unnecessary  dual  headings. 

Examples  are:  "REVIEW  CONFIGURATION"  (subheading:  "CURRENT  ACTIVE  CHANNEL 
CONFIGURATION");  "REVIEW  STATISTICS"  (subheading:  "CURRENT  CHANNEL  STATIS¬ 
TICS");  "MESSAGE  REPORTS"  (subheading:  "MESSAGE  REPORT  PARAMETERS" ) .  The 
subheadings  tend  to  be  redundant  and  somewhat  inconsistent  with  the  primary 
headings.  The  commands  (options)  selected  by  the  operator  to  produce  these 
screens  are  often  semantically  inconsistent  with  the  screen  titles  they 
produce.  Examples:  The  command  (option)  REVIEW  CONFIG  produces  a  screen 
called  "REVIEW  CONFIGURATION,"  which  should  be  "CONFIGURATION  REVIEW";  the 
command  (option)  "CHANNEL  STATS"  produces  the  screen  "REVIEW  STATISTICS," 
which  should  be  "CHANNEL  STATISTICS";  the  command  (option)  "MESSAGE  REPORTS" 
produces  "MESSAGE  REPORTS,"  which  shows,  not  message  reports,  but  message 
report  parameters  and,  therefore,  should  be  entitled  "MESSAGE  REPORT  PARAMETER 
SELECTION"  (an  extension  of  the  screen's  subtitle,  which  is  "MESSAGE  REPORT 
PARAMETERS")  or,  perhaps  better,  "MESSAGE  REPORT  DEFINITION";  the  command 
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(option)  "MAKE  REPORT"  produces  "REVIEW  REPORT,"  which  should  be  "MESSAGE 
REPORT . " 

Impact:  Student  and  operator  confusion. 

Comment:  The  information  provided  by  the  dual  headings  would  be  more  effec¬ 
tively  presented  in  single,  logical  headings  that  correspond  semantically  to 
the  commands,  or  menu  options,  that  generate  them. 

3.4(30.16)  Term:  "START  OVER"  (F10) . 

FINDING:  The  meaning  of  this  option,  which  is  presented  on  the  MESSAGE 
REPORTS  screen,  may  not  be  clear  to  the  operator  because  what  is  to  be 
restarted  is  not  clearly  indicated. 

Impact:  The  operator  may  wonder  how  far  back  into  the  procedures  the  function 
will  loop  and,  consequently,  may  hesitate  to  use  the  feature  when  it  would  be 
appropriate. 

Comment:  The  option  should  be  given  a  more  informative  name  that  indicates 
"reset  message  report  parameters  to  default  values."  Of  course,  the  "virtual" 
functions  keys  do  not  allow  room  for  more  than  two  groups  of  seven  characters 
each  to  describe  any  given  function- -another  reason  for  abandoning  this 
cumbersome  screen  index. 

3.4(31)  Operator  Errors  Resulting  from  Software  Interface . 

Two  types  of  errors  occurred  that  could  be  attributed  directly  to  defi¬ 
ciencies  in  operator -software  interface: 

3.4(31.1)  Accidental  reinitialization.  (See  also  Finding  3.4[4].) 

FINDING:  During  the  validation  test,  accidental  rebooting  of  the  system 

occurred  easily.  If  EXIT  (F14)  was  selected  from  the  RUNTIME  SYSTEM  screen 
(either  accidentally  or  purposefully),  the  operator  could  not  return  to  the 
screen  without  the  front-end  processors  being  reinitialized.  No  warning  was 
given  to  the  operator.  Prior  to  the  revalidation  test,  revisions  to  the 
software  effectively  solved  the  problem  of  accidental  reinitialization  via  the 
EXIT  function  key  (although  see  Finding  3.4[4]).  Three  examples  of  documented 
accidental  reinitialization  via  the  EXIT  function  are  described: 

(a)  In  one  recorded  instance,  the  operator  reported  that  the  system  did  not 
provide  sufficient  warning  when  he  "pressed  the  wrong  key." 

(b)  In  another  instance  a  system  engineer  reported  that  he  had  accidentally 
shut  down  the  system  when  coming  out  of  the  quick- look  procedure  before  he 
realized  what  was  happening;  he  did  not  know  what  exact  sequence  of  steps 
produced  the  result. 

(c)  A  third  instance  appeared  related  to  the  second:  The  operator  reported 
that  the  following  sequence  produced  accidental  reinitialization:  1--In 
RUNTIME  SYSTEM;  2- -Pressed  F13  UTILITIES;  3- -Chose  ALERT  QUEUES  from  UTILITY 
SYSTEM  menu;  4- -Received  AITG  ALERT;  5 --Pressed  F14  EXIT;  6- -In  UTILITY  SYSTEM 
menu;  7- -Pressed  F14  EXIT;  8- -In  MODE  SELECTION  menu;  9- -Should  have  pressed 
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F14  to  return  to  RUNTIME  SYSTEM,  but  pressed  a  different  key  by  mistake  [which 
key,  unknown] ,  which  reactivated  the  front-end  processors  without  warning. 

Impact:  Accidental  reinitialization  via  the  EXIT  function  would  not  reliably 
reactivate  all  of  the  previously  active  channels  and,  obviously,  involved  the 
possible  loss  of  important  test  data. 

Comment:  Reinitialization  or  shutdown  of  the  system  should  be  possible  only 
after  the  operator  has  been  strongly  warned  of  the  consequences  and  has  been 
required  to  perform  an  operational  step  that  is  sufficiently  dissimilar  to  all 
other  procedures  to  minimize  the  possibility  of  pressing  inappropriate  keys 
out  of  habit.  Software  revisions  incorporated  after  the  validation  test 
effectively  achieved  this  goal. 

3 .4(31 .2)  Zero  vs.  the  letter  0. 

FINDING:  The  operator,  attempting  to  follow  instructions  in  the  documen¬ 

tation  for  a  diagnostic  test,  typed  the  letter  instead  of  the  number.  The 
documentation  showed  the  number  zero  without  a  hash  mark;  the  operator  read  it 
as  the  letter  O. 

Impact:  The  operator  was  unable  to  perform  the  desired  test. 

Comment:  The  distinction  between  (f  and  0  should  be  clearly  indicated  in  the 

operator's  documentation  by  including  the  hash  mark  across  the  number. 

3.5  DCS  Operator  Hardware  Interface 

The  following  hardware  shortcomings  were  observed: 

3.5(1)  Power  generator. 

FINDING:  According  to  the  system  developer,  the  generator  engine  is  known 
to  have  the  tendency  to  run  rich  after  several  days  (50  hours)  of  operation. 
The  spark  plugs  in  the  two  center  cylinders,  which  are  closest  to  the  center 
of  the  intake  manifold,  tend  to  get  fouled.  When  this  occurred  during  the 
validation  test,  replacement  plugs  were  not  immediately  available.  (See  also 
Finding  2. 4 [11] .) 

Impact:  Power  source  becomes  unreliable.  The  two  spark  plugs  must  be 
changed. 

Comment:  Extra  plugs  should  be  carried  with  the  system  at  all  times. 

3.5(2)  Power  cable  connector . 

FINDING:  The  power  cable  connector  on  the  vehicle  exterior  has  a  collar 
that  tightens  counterclockwise  from  the  installer's  position. 

Impact:  The  requirement  to  tighten  the  connector  by  turning  the  collar 
counterclockwise  is  counter  intuitive  and  tends  to  fool  new  personnel  until 
they  learn  that  the  correct  procedure  is  "backwards." 


35 


Comment:  It  was  suggested  that  some  sort  of  directional  arrow  and  a  legend  be 
placed  on  or  near  the  cap.  The  developer  added  appropriate  labeling  prior  to 
the  validation  test. 

3.5(3)  Fire  extinguisher. 

FINDING:  The  locking  pin  on  the  handle  of  the  fire  extinguisher  included 
with  the  equipment  was  not  retained  with  a  seal.  It  was  easily  removable. 

Impact:  The  absence  of  a  seal  causes  a  potential  user  to  question  whether  the 
canister  is  charged  appropriately.  The  canister  could  have  been  accidentally 
emptied. 

Comment:  The  problem  was  corrected  by  the  developer  prior  to  the  validation 
test . 

3.5(h)  COES  antenna. 

FINDING:  The  turn  screw  for  locking  the  satellite  antenna  mount  in 
position  is  not  captive. 

Impact:  The  screw  could  be  lost,  especially  during  vehicle  movement,  when  it 
could  vibrate  loose  if  not  tightened  down. 

Comment:  All  operated  screws,  pins,  locks,  tie  downs,  and  the  like  should  be 

captive  to  prevent  accidental  loss.  (The  GOES  antenna  itself  is  normally 
stowed  safely  during  movement.) 

3.5(5)  GOES  antenna  lead  wire. 

FINDING:  The  wire  is  strung  loosely  over  the  top  of  the  shelter  from  the 

antenna  to  the  connector  on  the  side  of  the  shelter. 

Impact:  The  ample  slack  in  the  wire  would  allow  a  brisk  wind  (less  than 
35  mph)  to  blow  the  wire  off  the  shelter  top  and  down  across  the  back  of  the 
shelter  and  the  shelter  door.  Although  perhaps  unlikely,  the  wire  could  be 
damaged  by  the  opening  and  closing  of  the  heavy  door,  especially  if  it  were  to 
fall  between  the  hinge  edge  of  the  door  and  the  outside  shelter  wall  when  the 
door  is  open. 

Comment:  Although  the  presence  of  the  curbside  receive/transmit  antenna  mast, 
when  it  is  mounted,  would  help  to  keep  the  GOES  antenna  wire  on  the  roof  of 
the  shelter.  An  additional  helpful  measure  would  be  to  attach  a  guy  device 
atop  the  shelter  near  the  rear  curbside  corner  where  the  wire  could  be 
secured.  An  interim  substitute  for  the  latter  procedure  would  be  to  tie  off 
the  slack  at  the  handhold  located  topside. 

3.5(6)  Junction  box  (shelter  exterior) . 

FINDING:  During  the  validation  test,  some  of  the  Velcro  strips  that  hold 

the  canvas  flaps  in  place  when  the  cover  is  raised  were  beginning  to  come 
loose . 
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Impact:  The  flaps  are  seldom  used,  but  there  may  be  times  during  which  they 
should  be  used,  as  during  certain  severe  weather  conditions.  Without  effec¬ 
tive  fasteners  the  flaps  will  not  be  used. 

Comment:  Prior  to  the  revalidation  test,  the  loose  strips  were  replaced. 

3.5(7)  Padlocks. 

FINDING:  Padlocks  were  provided  for  locking  the  antenna  storage  tubes  and 

the  exterior  storage  compartments,  but  there  was  no  method  provided  for 
temporarily  closing  these  spaces  if  the  padlocks  became  unavailable. 

Impact:  The  storage  compartments  could  not  be  used  during  transit  without  a 

means  of  securing  their  openings. 

Comment:  Prior  to  the  validation  test,  the  developer  secured  the  padlocks  at 

their  appropriate  locations  with  chains. 

3.5(8)  Padlock  retaining  chains. 

FINDING:  There  are  two  padlock  chains  on  each  of  the  two  exterior  storage 
compartments  doors.  Each  of  the  four  chains  forms  a  stiff,  three-  to  four- 
inch  loop  that  protrudes  approximately  two  inches  outward  from  the  widest  part 
of  the  vehicle . 

Impact:  The  chains  are  vulnerable  to  catching  on  brush  or  other  objects  that 
might  be  encountered  in  tight  maneuvering. 

Comment:  The  retaining  screw  for  each  chain  needs  to  be  relocated  so  that 

while  the  padlocks  are  in  place  the  chains  are  situated  horizontally  in  a 
straight  line,  allowing  sufficient  slack  only  for  installation  and  removal  of 
the  padlocks . 

3.5(9)  Shelter  door  (ladder  hanger). 

FINDING:  During  the  validation  test,  there  was  a  ladder  hanger  on  the 

inside  of  the  shelter  door  that  was  not  used  or  needed. 

Impact:  Probably  minimal;  but  the  hanger  could  catch  on  clothing  or  otherwise 

get  in  the  way. 

Comment:  A  new  staircase  ladder  with  improved  foot  traction,  which  replaces 
an  earlier  version  that  used  the  hanger,  is  now  stowed  in  the  generator 
trailer.  Prior  to  the  revalidation  test,  the  hanger  was  removed. 

3.5(10)  Tie-downs. 

FINDING:  Rubber  bungee  straps  are  provided  as  tie  downs  for  equipment 
during  vehicle  movement.  Within  the  shelter  they  are  used  to  secure  such 
items  as  the  CRT  monitor  and  keyboard,  the  operator  chairs,  a  tool  case,  and  a 
first  aid  kit.  In  the  generator  trailer,  they  are  used  to  restrain  extra  fuel 
cans  and  other  equipment.  One  operator  reported  an  occasion  in  which  one  of 
the  straps  broke  during  application. 
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Impact:  The  straps  provide  an  interim  solution  for  securing  equipment,  but 
they  are  awkward  to  install  and  possibly  unreliable.  Because  they  are  not 
customized  for  specific  applications,  they  require  the  operator  to  decide 
where  and  how  „  attach  them- -there  is  no  prescribed  way.  They  may  be  lost  or 
misplaced  and  constitute  a  supply  requirement.  The  item  most  at  risk  is  the 
CRT  monitor. 

Comment:  The  CRT  shelf  should  provide  secure  attachments  (e.g.,  hasps,  or 
other  easily  operated  connectors)  for  the  CRT.  Each  item  of  equipment 
requiring  stowing  and  unstowing  and  which  is  subject  to  damage  or  which  may 
damage  other  equipment  during  movement  should  be  provided  customized  stowage 
with  built-in,  easily-operated  mechanisms  for  securing  and  unsecuring. 

3.5(11)  Utility  drawer  latches. 

FINDING:  Gravity  holds  the  latches  in  the  locked  position.  The  operator 
must  turn  the  latch  upward  to  allow  the  drawer  to  be  opened.  It  can  be  turned 
only  one  way  because  of  protruding  bolt  heads  on  the  drawer  frame.  When  the 
drawer  is  pulled  out,  the  latch  is  released  and  it  falls  back  into  the  locked 
position  so  that  it  must  be  lifted  again  before  the  drawer  can  be  closed  and 
secured. 

Impact:  It  requires  two  hands  to  open  or  close  the  drawer,  one  to  hold  the 

latch,  one  to  move  the  drawer.  It  was  not  uncommon  for  the  operators  to 
forget  that  the  latch  had  to  be  lifted  in  order  to  close  the  drawer;  in  these 
instances,  the  drawer  was  slammed  against  the  latch,  which,  of  course,  then 
reminded  the  operator  to  lift  the  latch. 

Comment:  Consider  redesigning  the  drawer  latches. 

3.5(12)  Lights  switch. 

FINDING:  The  interior  shelter  lights  switch  was  not  labeled. 

Impact:  The  purpose  of  the  switch  was  not  immediately  apparent. 

Comment:  Labeling  was  added  prior  to  the  revalidation  test. 

3.5(13)  Ceiling  lights. 

FINDING:  The  fluorescent  ceiling  lights  inside  the  shelter  are  reflected 
from  the  oscilloscope  windows  directly  into  the  operator's  eyes. 

Impact:  It  is  difficult  for  the  operators  to  read  the  oscilloscopes;  they 

hold  up  a  hand  to  shade  their  eyes  from  the  glare. 

Comment:  Moving  the  location  of  the  scopes,  as  suggested  in  Finding  3.5(22), 
would  solve  this  problem. 

3.5(14)  Cabling. 

FINDING:  Installation  cables  were  identified  by  labeling  and  referenced 

in  diagrams.  One  technician  noted  that  a  useful  addition  to  the  system  would 
be  the  visual  coding  of  installation  cables,  which  would  allow  visual  tracing 
at  a  glance. 
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Impact:  Maintenance  time  is  increased  and  made  more  difficult  if  cable 
tracing  is  problematical.  Wire  bundles  may  have  to  be  unwrapped  or  a  continu¬ 
ity  test  performed  to  locate  related  cable  connectors. 

Comment:  If  it  is  not  possible  to  trace  visually  the  entire  length  of  an 

individual  cable,  it  would  be  helpful  if  the  cable  ends  were  similarly  marked 
and  distinguishable  from  the  markings  of  other  cables  in  the  vicinity.  This 
would  provide  a  means  for  easily  relating  the  two  ends  of  a  given  cable,  espe¬ 
cially  when  the  cable  is  bundled  or  intertwined  with  others  or  located  in  a 
cramped  or  dimly  lit  location.  Identically  coded  collars  with  patterns  and 
bright  colors  could  be  placed  adjacent  to  the  connector  at  both  ends  of  a 
cable.  (The  system  developer  notes  that  some  of  the  cables  are  interchange¬ 
able,  which  might  preclude  using  specific  plug-to-jack  coding.) 

3.5(15)  Air  conditioner . 

FINDING:  The  operators  acknowledged  that  the  air  conditioner  was  noisy, 
but  that  it  did  not  bother  them;  they  said  they  had  adapted  to  the  point  that 
they  were  normally  unaware  of  it. 

Impact:  Minimal  negative  impact. 

Comment:  There  are  three  fan  speeds.  The  system  developer  reports  that  the 

lowest  speed  is  about  3dBA  lower  in  radiated  sound  level  than  the  highest  and 
that  part  of  the  noise  emanates  from  air  flow  over  EMI  filters  in  the  louvre 
areas.  The  developer  also  noted  that  a  quieter  unit  could  be  substituted  were 
it  desired.  At  this  time,  there  does  not  appear  to  be  a  significant  need  to 
replace  the  current  unit,  but  a  quieter  unit  is  recommended  for  future 
versions  of  the  system. 

3.5(16)  Air  conditioner  switch  labeling. 

FINDING:  The  meaning  of  the  term  "condition"  on  the  VENT/OFF/CONDITION 
switch  is  unclear.  When  one  operator  was  asked  to  explain  the  label,  he  could 
not.  He  only  knew  that  he  was  supposed  to  put  it  in  the  "condition"  position. 

Impact:  Use  of  the  air  conditioner  may  be  confusing  to  new  operators. 

Comment:  Does  "condition"  mean  "recirculate"?  Does  it  apply  to  both  HEAT  and 

COOL?  Clarify  by  relabeling. 

3.5(17)  Emergency  light  labeling. 

FINDING:  The  meaning  of  the  labeling  is  not  clear.  On  the  side  of  the 
"Enable/Disable"  switch  box  is  an  LED  with  a  test  switch.  The  LED,  which  is 
normally  on,  is  labeled  "CHARGE  MONITOR,"  which  to  the  uninitiated  could  mean 
either  "charge  the  monitor"  or  "monitor  the  charge."  The  test  switch,  labeled 
"PRESS  TO  TEST,"  is  a  toggle  that  must  be  pushed  down  rather  than  in,  as  the 
label  would  seem  to  imply.  When  the  test  switch  was  tried,  nothing  happened. 

Impact:  Student  and  operator  confusion.  Some  operators  may  have  to  be  told 
what  the  "CHARGE  MONITOR"  label  means.  The  LED,  normally  on,  is  apparently 
meant  to  signal  a  problem  when  it  is  not  on,  but  then  it  would  probably  not  be 
noticed. 
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Comment:  (a)  The  meaning  of  labeling  should  be  self-evident  and,  unless 

necessary,  not  constitute  another  learning  hurdle,  (b)  Either  the  operation 
of  the  LED  should  be  reversed,  which  might  cause  electronic  complications,  or 
additional  labeling  should  be  added  to  indicate  its  purpose  clearly.  (c) 
Operation  of  the  emergency  light  should  be  covered  in  system  documentation. 

The  operator  should  not  encounter  a  situation  in  which  the  test  switch  is 
tried  with  no  response  from  the  system  unless  the  switch  is  accompanied  by 
instructions  indicating  when  such  an  occurrence  is  normal. 

3.5(18)  Printer  location. 

FINDING:  The  current  location  of  the  printer  (directly  across  the  shelter 
aisle  from  the  operator's  console)  may  not  be  ideal.  It  occupies  the  space 
most  logically  suited  for  operator  writing,  referencing  of  manuals,  and  so  on. 
Furthermore,  the  current  orientation  of  the  printer  (front  of  printer  toward 
aisle)  leaves  less  than  a  page  length  of  space  behind  it  for  continuous  paper 
to  feed  and  accumulate . 

Impact:  (a)  Having  swiveled  around  (up  to  90  degrees)  to  use  the  desk  surface 

on  the  roadside  of  the  aisle,  the  operator  must  lean  forward  toward  (or  roll 
the  operator's  chair  toward)  the  shelter  access  door  to  use  the  available  desk 
surface.  The  problem  would  be  exacerbated  for  the  left-handed  operator.  (b) 
Accumulating  paper  does  not  stack  appropriately  behind  the  printer. 

Comment:  A  better  location  and  orientation  for  the  printer  may  be  the 
following:  Place  the  printer  so  that  it  faces  the  front  wall  of  the  shelter, 

with  its  right  side  as  close  to  the  curbside  of  the  shelter  as  possible  while 
allowing  sufficient  hand  space  between  the  printer  and  the  curbside  wall.  Set 
the  back  edge  of  the  printer  as  close  to  the  rear  wall  as  possible  while 
allowing  sufficient  space  for  the  accumulation  of  continuous  paper.  While 
this  places  the  printer  farther  from  the  operator,  the  disadvantage  is  minimal 
because  the  operator  does  not  need  frequent  access  to  the  printer.  With  the 
printer  in  this  location,  all  of  the  desk  surface  closest  to  the  operator 
becomes  available  for  the  operator's  use.  The  desk  surface  would  be  accessi¬ 
ble  to  the  right-handed  operator  who  swivels  clockwise  90-180  degrees  and  to 
the  left-handed  operator  who  swivels  clockwise  135-180  degrees. 

3.5(19)  Circuit  breaker  panel. 

FINDING:  This  panel  was  examined  in  one  of  the  DCS  vans  during  the 

validation  test.  The  cover  on  the  panel  (curbside  wall,  lower  left  of 
operator)  had  no  labeling  (the  contents  were  not  identified).  The  panel 
behind  the  cover  contained  four  switch  locations  and  three  switches  (one 
switch  location  was  empty) .  One  of  the  three  switches  (upper  left  corner  of 
panel)  had  no  label,  but  was  white  in  color  as  if  to  distinguish  its  function 
from  the  others,  which  were  black.  The  other  two  switches  were  labeled  CB14 
and  CB15.  The  switch  handle  on  CB15  was  broken  off.  The  empty  switch  hole 
was  labeled  CB16.  The  operator  was  able  to  find  CB14  and  CB15  on  the  AC  wire 
diagram,  but  not  CB16  or  the  white  switch. 

Impact:  Whether  or  not  the  broken  switch  on  CB15  could  be  manipulated  with  a 
tool  such  as  a  screwdriver  was  undetermined.  There  was  some  confusion  about 
the  purpose  of  the  CB16  label- -was  there  a  switch  missing?  Even  if  operators 
were  trained  in  the  use  of  this  panel  (apparently  they  were  not) ,  the  absence 
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of  Informative  labeling  would  make  it  unnecessarily  difficult  to  remember  the 
switch  functions  because  of  their  infrequent  use. 

Comment:  Include  informative  labeling  on  both  the  cover  and  the  switches.  If 

the  white  color  of  the  unlabeled  switch  is  significant,  so  indicate;  if  not, 
ensure  that  like  switches  have  the  same  color.  Fix  the  broken  switch. 

3.5(20)  A.C.  power /generator  monitor/control  panel  dials. 

FINDING:  The  dials  on  the  left  side  of  this  panel,  which  monitor  "INPUT 
POWER"  and  "U.P.S.  POWER"  have  what  are,  seemingly,  strips  of  green-colored 
paper  pasted  above  the  scales  to  indicate  normal  (or  acceptable)  ranges.  The 
colored  strips  are  crudely  made  (apparently,  by  hand)  and  are  beginning  to 
buckle  and  peel  off  three  of  the  five  dials  (checked  only  in  one  of  the  two 
DCS  shelters).  On  the  top  two  dials  ("A.C.  VOLTS"  for  "INPUT  POWER"  &  "U.P.S. 
POWER"),  the  strips  have  red  colored  bands  at  either  end  of  the  strips  to 
indicate  danger  (or  unacceptable)  ranges.  The  green  and  red  colors  are  not 
highly  saturated. 

Impact:  Besides  being  of  questionable  durability,  the  strips  are  not  colored 

adequately.  The  red-green  color-deficient  person  may  be  unable  to  distinguish 
either  the  red  or  the  green  and,  more  important,  be  unable  to  distinguish  the 
red  from  the  green.  Both  of  these  effects  were,  in  fact,  observed  in  one  such 
person. 

Comment:  The  strips  should  be  redone  so  that  they  are  durable  and  are  colored 
to  maximize  the  distinction  between  the  green  and  the  red. 

3.5(21)  Uninterruptible  power  source  dials. 

FINDING:  The  two  dials  ("AC  VOLTS"  &  "DC  VOLTS")  on  the  U.P.S.  unit 
(bottom  unit  in  power  rack)  have  poor  viewing  angles .  While  the  operator  can 
see  the  position  of  the  needles,  the  scales  above  them  are  not  in  view  from 
the  normal  operating  position. 

Impact:  Minimal,  in  this  system. 

Comment:  This  is  a  common  manufacturing  "defect"  that  prevents  easy  reading 
of  the  dials  unless  the  viewer  is  positioned  rather  directly  in  front  of  the 
dial  windows.  The  actual  dials  are  inset  behind  the  windows  so  that  the 
window  frame  cuts  off  the  viewing  angle .  The  only  recourse  for  the  user  is  to 
position  the  equipment  where  operators  can  see  the  dials  easily. 

3.5(22)  Panel  equipment  positioning. 

FINDING:  The  relative  positions  of  the  GOES  antenna  readout  ("N.B.S. 
time"),  modem,  speaker  bank,  and  oscilloscope  bank  are  not  optimal.  The 
present  configuration  puts  the  often-viewed  oscilloscopes  at  the  top  of  the 
rack,  high  above  the  operator's  eye  level. 

Impact:  Although  the  operators  did  not  complain  about  the  current  configura¬ 
tion,  they  were  observed  to  strain  their  necks  constantly  upward.  For  opera¬ 
tors  with  bifocal  or  trifocal  lenses  (one  operator  wore  trifocals) ,  this  could 
be  troublesome  during  normal  operations,  which  are  often  sustained. 
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Comment:  The  speaker  rack  should  be  at  the  top  because  it  does  not  need  to  be 
viewed.  Under  it  should  be  the  satellite  time  readout  receiver,  which  does 
not  have  to  be  viewed  with  great  frequency.  The  oscilloscopes  should  be  third 
down  in  the  rack  because  the  operator  frequently  refers  to  them.  The  most 
frequent  reference  point  above  the  CRT  monitor  is  the  modem  panel;  therefore, 
it  should  be  as  low  as  possible  without  obstructing  the  view  of  the  CRT. 
According  to  the  system  developer,  there  is  no  system  constraint  that  would 
make  reordering  these  items  unadvisable;  therefore,  they  should  be  reordered. 

3.5(23)  Modem  panel.  (See  also  Finding  2.4[8].) 

FINDING:  The  most  frequently  referred -to  rows  of  LEDs  are  at  the 
the  panel.  The  least  frequently  viewed  rows  are  at  the  bottom. 

Impact:  The  operator  must  look  higher  for  the  more  frequently  needed 

references . 

Comment:  Though  not  of  drastic  importance,  the  ideal  ordering  of  the 

would  put  the  least  often  viewed  at  the  top  and  the  most  often  viewed 
bottom. 

3.5(24)  Keyboard  &  shelf. 

FINDING:  The  keyboard  is  too  wide  for  its  sliding  shelf;  it  overlaps  at 
both  ends .  The  keyboard  contains  many  keys  that  are  not  used  by  the  DCS 
software  (e.g.,  the  "Help"  key  and  the  entire  right-hand  bank  of  18  keys). 

Impact:  Because  of  its  width  (required  by  the  unused  keys),  the  keyboard 

cannot  be  stowed  either  on  its  pullout  shelf  or  on  the  monitor  shelf  during 
system  transport.  Operators  may  wonder,  for  example,  why  the  "Help"  key  (in 
the  F15  position)  is  not  used  for  the  HELP  option. 

Comment:  A  narrower  keyboard  would  be  much  better,  from  the  standpoint  of 
both  physical  size  and  operator  usage.  A  smaller  keyboard  would  also  allow 
the  incorporation  of  an  additional  feature:  Another  sliding  shelf  could  be 
installed  just  above  the  current  keyboard  shelf.  The  shelf  on  which  the 
monitor  now  rests  could  be  moved  up  enough  to  accommodate  the  new  shelf 
without  making  the  monitor  too  high  (the  current  height  of  both  the  keyboard 
and  monitor  is  appropriate) .  The  new  shelf  would  accept  the  keyboard,  which 
would  be  clamped  to  it.  It  would  be  able,  with  the  keyboard  installed  on  it, 
to  slide  in  beneath  the  monitor  shelf.  Because  the  keyboard  is  not  used 
constantly,  it  could  remain  in  the  stowed  position  much  of  the  time,  during 
which  the  current  keyboard  shelf  would  be  available  as  an  excellent  writing 
surface  or  surface  for  reading  manuals,  or  performing  other  duties.  (The 
pullout  keyboard  shelf  provides  for  knee  room,  since  there  is  no  knee  well. 

The  pullout  feature  is  a  modification  of  the  original  stationary  shelf  that 
provided  no  knee  room.) 

3.5(25)  Keyboard  dust  cover. 

FINDING:  The  keyboard  used  during  the  training  classes  was  protected  by  a 
type -through  plastic  dust  cover. 


top  of 


LED  rows 
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Impact:  The  cover  was  annoying  to  some  personnel.  It  tended  to  make  the 
operator's  or  technician's  fingers  stumble  and  reduced  the  readability  of  the 
keys,  especially  the  frequently  used  function  keys. 

Comment:  It  was  suggested  that  removing  the  covers  would  not  entail  undue 

risk,  since  contamination  by  dust,  liquids,  and  so  on  should  be  minimal  under 
most  operational  circumstances .  Prior  to  the  validation  test  the  covers  were 
removed.  Terminal  users  should  be  trained  to  exercise  normal  precautions. 

3.5(26)  Computer  mount . 

FINDING:  The  MicroVAX  II  computer  is  mounted  in  an  equipment  rack  and 
bolted  in  place.  The  bolt  holes  in  the  mounting  rack  did  not  line  up  well 
with  the  frame  of  the  computer. 

Impact:  On  one  occasion  during  the  validation  test,  two  operators  were 
observed  having  extreme  difficulty  mounting  the  computer.  It  was  necessary  to 
lift  the  heavy  computer  while  attempting  to  insert  the  bolts  at  the  same  time 
--a  two-person  task. 

Comment:  The  support  contractor  reported  that  the  rack  alignment  was  good 

prior  to  system  transport  and  that  a  shift  had  occurred  during  transit. 
Apparently  the  racks  are  not  constructed  to  completely  resist  the  jolting  and 
twisting  motions  accompanying  normal  system  transport.  The  solution,  accord¬ 
ing  to  the  support  contractor  is  to  enlarge  the  holes  in  the  mounting  rack, 
which,  reportedly,  they  could  easily  accomplish. 

3.5(27)  Computer  cover  panel. 

FINDING:  The  top  panel  of  the  MicroVAX  computer  is  secured  by  36  screws. 
Using  a  high-speed  hand-held  drill,  a  technician  required  approximately  4.5 
minutes  to  remove  all  screws  and  approximately  3.5  minutes  to  reinsert  and 
tighten  them.  The  front  panel  holds  10  screws,  requiring  about  1  minute  to 
remove  and  2  minutes  to  install . 

Impact:  The  total  labor  time  involved  in  removing  and  replacing  both  panels 

is  about  11  minutes . 

Comment:  The  process  is  quite  time  consuming.  Can  doctrine  allow  the  use  of 
fewer  screws  during  non- secure  operations?  Are  all  the  screws  necessary,  even 
for  secure  operations?  (During  the  revalidation  test,  the  operator- 
technicians  conducted  operations  with  only  a  few  of  the  screws  in  place  so 
that  the  cover  could  be  quickly  removed  if  necessary.) 

3.5(28)  Computer  access  door.  (See  also  Finding  2. 4 [10].) 

FINDING:  The  computer  access  door,  which  should  be  closed  during  normal 
operations,  displays  no  notice  of  that  requirement  to  the  operator.  The 
operators  were  fairly  conscientious  about  keeping  the  door  closed. 

Impact:  Some  operators  might  establish  an  undesirable,  relaxed  attitude 

toward  the  need  (especially  during  secure  operations)  for  keeping  the  door 
closed. 
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Comment:  Both  the  inside  and  outside  of  the  door  should  display  an  appropri¬ 
ate  notice.  Keeping  the  door  closed  not  only  allows  secure  operations,  but 
helps  to  regulate  computer  temperature  and  to  prevent  the  entry  of  fo-eign 
objects  into  the  compartment  that  houses  the  disk  drive  and  recorder. 

3.5(29)  Computer  panel  lock  &  key. 

3.5(29.1)  Operating  with  panel  buttons  enabled  or  key  i*'  lock. 

FINDING:  At  times,  operators  were  observed  operating  with  the  computer 
panel  lock  in  the  unlocked  position,  sometimes  with  the  key  still  in  the  lock. 

Impact:  (a)  When  the  panel  is  not  locked,  the  panel  buttons  could  be  inadver¬ 

tently  activated,  which  would  halt  operations  and  perhaps  cause  a  loss  of 
mission  data.  (b)  In  one  incident,  a  shelter  occupant  brushed  against  the 
front  panel  of  the  computer  with  his  leg,  causing  the  panel  lock  (in  which  the 
key  was  still  inserted  in  the  unlocked  position)  to  break  out  of  the  panel. 

The  lock  mechanism  had  to  be  replaced.  (Incidentally,  had  the  lock  been  in 
the  locked  position,  as  it  should  have  been,  the  operator  would  not  have  been 
able  to  shut  down  the  system  normally.) 

Comment:  Despite  the  fact  that,  in  this  particular  situation,  having  left  the 

lock  unlocked  allowed  the  operator  to  perform  a  normal  shutdown,  the  DCS 
should  not  be  operated  with  the  key  still  in  the  lock  or  the  lock  in  the 
unlocked  position.  Operators  should  be  reminded  of  the  importance  of  dis¬ 
abling  the  panel  buttons  and  removing  the  key  while  operating.  A  warning  to 
that  effect  should  be  posted  in  a  prominent  location,  such  as  on  a  list  of 
important  operational  considerations  placed  high  on  the  inside  surface  of  the 
shelter  door. 

3.5(29.2)  Computer  lock  unlabeled. 

FINDING:  The  lock  has  no  accompanying  labeling  or  instructions  to 
indicate  its  purpose  or  how  it  functions . 

Impact:  The  operator  cannot  tell  by  looking  at  the  panel  buttons  whether  they 
have  been  disabled  or  not.  The  only  clue  is  the  position  of  the  keyhole,  the 
significance  of  which  the  operator  is  forced  to  remember  without  the  aid  of 
labeling.  If  the  operator  is  unsure  of  the  proper  direction  in  which  to  turn 
the  key  to  disable  the  buttons,  the  key  may  be  turned  in  the  wrong  direction, 
causing  the  computer  to  reboot  with  the  possible  loss  of  important  data. 

Comment:  The  lock  and  its  functions  should  be  clearly  labeled.  There  is  room 
for  a  label  decal  on  the  top  surface  of  the  computer  panel  just  above  the 
lock.  The  lock  mechanism  should  have  a  detent  that  would  proscribe  moving  the 
key  into  the  "reboot"  position  accidentally. 

3.5(30)  Computer  panel  display-control  toggle  switches .  (See  also 
Finding  2. 4[9] .) 

FINDING:  The  three  toggle  switches  were  labeled  S3,  S2,  and  Si  from  left 
to  right,  respectively. 
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Impact:  The  labels  impart  no  meaning  to  operator  regarding  the  functions  of 
the  switches.  The  numerical  order  of  the  switches  is  opposite  to  intuitive 
expectations . 

Comment:  There  is  little  space  for  these  labels.  Nevertheless,  it  may  still 

be  possible  to  use  labels  that  have  more  mnemonic  value. 

3.5(31)  Generator  alarm. 

FINDING:  An  audible  alarm  sounds  if  the  generator  shuts  down  abnormally, 
as,  for  example,  when  the  fuel  tanks  become  empty.  The  alarm  does  not  sound 
prior  to  impending  shutdown. 

Impact:  Abnormal  loss  of  generator  power  is  normally  quite  apparent  even 

without  the  alarm,  because  the  shelter  lights  go  out.  The  uninterruptible 
power  source  keeps  the  computer  functioning  for  a  time  without  the  generator . 

Comment:  Much  more  helpful  would  be  an  alarm  that  warns  of  impending  shutdown 

due  to  empty  fuel  tanks.  While  a  fuel  gauge  is  provided  inside  the  shelter 
for  the  operator,  its  location  is  behind  the  operator’s  back,  and  the  operator 
is  not  inclined  to  check  it  periodically. 

Section  4;  Safety 


4.1  M-880  Truck  with  Shelter 

FINDING:  The  operators  reported  that  the  center  of  gravity  is  shifted  to 

the  rear  because  of  the  weight  of  the  S- 710/M  shelter  and  its  equipment,  and 
that  at  55-60  mph  the  vehicle  is  unstable  on  uneven  roads.  Furthermore,  they 
stated  that  the  weight  of  the  shelter  appears  to  be  unevenly  distributed,  with 
more  on  the  curbside,  which  might  contribute  to  the  shelter's  tendency  to 
"rock"  during  movement  and  during  operations  when  the  wind  is  high.  They  also 
noted  that  the  effect  seems  to  be  greater  without  the  M101A2  generator  trailer 
attached. 

Impact:  The  operators  felt  that  the  instability  of  the  vehicle  could  create  a 
lack  of  mobility  or  even  a  safety  hazard  in  the  field.  One  operator  reported 
that  during  training  prior  to  the  validation  test  he  had  experienced  queasi¬ 
ness  while  operating  on  a  windy  day. 

Comment:  A  determination  needs  to  be  made  regarding  the  adequacy  of  the 

current  configuration  from  the  standpoint  of  both  safety  and  mobility.  The 
operators  suggested  that  the  shelter  needs  to  have  some  sort  of  stabilization 
device  to  prevent  it  from  rocking  in  the  wind  during  operations.  The  Army  has 
asked  the  developer  to  look  into  the  matter. 

4 .2  Shelter  Entrance  Way 

FINDING:  The  low  profile  of  the  top  of  the  doorway  presents  a  constant 
threat  to  persons  entering  or  leaving  the  shelter. 

Impact:  During  the  validation  test,  one  person  received  a  bleeding  cut  to  the 

top  of  his  head.  Others  reported  hitting  their  heads. 


45 


Comment:  This  is  a  common  complaint  for  shelters  of  this  type.  Nevertheless, 
serious  injury,  though  improbable,  could  occur.  Minor  injuries  will  occur 
from  time  to  time  in  the  life  of  the  system.  Consider  retrofitting  the 
entranceway  with  some  sort  of  padded  protection. 

4 .3  Halogen  Desk  Lamp 

FINDING:  The  100  watt  halogen  desk  lamp  (ELECTRIX,  Model  2V945)  generates 
much  heat,  which,  besides  providing  an  additional  burden  for  the  air  condi¬ 
tioner,  constitutes  a  physical  safety  hazard  for  personnel  and  a  possible  fire 
hazard. 

Impact:  A  person  who  sits  on  the  shelf  beneath  the  light  (a  natural  place  for 

an  observer)  may  receive  a  burn  or  clothing  may  be  damaged.  One  such  instance 
occurred  prior  to  the  validation  test:  A  person  seated  on  the  shelf  with  his 
shoulder  beneath  the  lamp  was  unaware  that  his  jacket  had  started  to  smoke. 

He  was  warned  by  others,  and  no  injury  or  serious  destruction  occurred. 

Comment:  The  lamp  should  be  removed  or  replaced  by  a  light  source  that 

presents  no  hazard. 


Conclusions 

Many  evaluative  comments  pertaining  to  the  C3I2  DCS  have  been  made. 
However,  as  with  any  detailed  examination  of  a  system,  the  sheer  number  of 
findings  may  tend  to  reflect  more  the  level  of  detail  of  the  evaluation  than 
the  overall  quality  of  the  system.  Considering  the  prototype  nature  of  the 
DCS,  the  absence  of  "high  drivers"  (such  as  time  pressure  on  system  operators 
and  complex  operational  tasks) ,  and  the  significant  improvements  effected 
since  this  evaluation  began,  the  system  can  be  considered  satisfactory  with 
regard  to  most  general  MANPRINT  concerns. 

Manpower  and  personnel  considerations  were  minimal,  centering  largely  on 
whether  or  not  contractor  technicians  should  be  used  as  system  operators.  It 
was  suggested  that  an  effective  use  of  manpower  would  place  military  enlisted 
personnel  in  the  operator's  position  and  use  contractor  personnel  as  system 
controllers  and  maintainers. 

As  for  training ,  it  was  noted  that  the  prototype  DCS  should  be  fairly  easy 
to  operate.  Therefore,  the  amount  of  time  required  to  train  system  operators 
should  not  be  extensive.  However,  no  formal  training  evaluation  was  conducted 
(owing  to  the  absence  of  a  training  program);  therefore,  this  conclusion  is 
tentative  and  needs  empirical  validation. 

From  a  human  factors  engineering  perspective,  many  small  improvements 
could  be  made;  indeed,  many  have  been  implemented  as  a  result  of  this  evalua¬ 
tion.  In  general,  the  system  appears  to  have  been  given  reasonable,  if  not 
thorough,  human  factors  attention,  and  future  decisions  regarding  changes  in 
non-crucial  areas  of  the  prototype  DCS  design  should  be  based  upon  consid¬ 
erations  of  cost  and  ease  of  accomplishment. 

Many  of  the  lesser  human  factors  findings  could  be  overlooked  without 
great  injury  in  the  prototype  DCS,  but  some  would  take  on  greater  importance 
in  subsequent  versions  of  the  system.  Several  findings  were  of  major  import, 
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even  for  the  prototype  system,  and  they  required  attention.  The  system 
developer  has  already  implemented  suggested  changes  in  several  areas  and  has 
begun  implementation  of  others.  All  of  the  findings  should  be  considered  for 
whatever  implications  they  might  have  for  the  development  of  the  DRS  and  the 
next  version  of  the  DCS. 

Few  system  safety  findings  emerged- -the  most  important  involving  vehicle 
instability.  No  health  hazard  was  associated  with  the  system. 

The  following  summarizes  primary  MANPRINT  concerns  for  the  prototype  DCS 
system  in  terms  of  whether  or  not  they  have  been  resolved. 

Largely  Unresolved  Issues 

•  Military  enlisted  personnel  as  DCS  operators  may  be  more  appropriate 
than  contractor  technicians,  whose  technical  skills  are  not  utilized  effec¬ 
tively  at  the  operator's  position.  (Finding  1.1) 

•  Formal,  separate  training  courses  and  system  documentation  need  to  be 
developed  for  operators  and  maintainers  of  the  system,  without  which  gaps  in 
skills  and  knowledge  will  occur.  (Findings  2.1  &  2.4) 

•  Training  time  for  DCS  operators  should  not  be  extensive  (probably  less 
than  a  week).  Empirical  validation  of  this  assertion  is  needed. 

(Finding  2.3) 

•  Total  system  setup  and  teardown  times  appear  to  be  excessive,  owing 
substantially  to  the  amount  of  time  required  for  antenna  erection  and 
takedown.  (Findings  3.2  &  3.3) 

•  The  system  needs  an  effective  self  test  for  determining  that  it  is 
functioning  properly  both  before  and  during  data  collection  sessions. 

(Finding  3. 4 [2]) 

•  Conceptual  complexity  of  the  software  interface  could  be  reduced 
significantly  for  the  student  in  areas  such  as  general  screen  clutter,  menu 
design,  and  system  terminology.  Significant  improvements  have  been  made  in 
some  instances,  but  much  remains  to  be  done.  (Findings  3. 4 [27],  [29],  &  [30]) 

•  Panel  equipment  should  be  repositioned,  especially  the  oscilloscopes, 
which  catch  glare  from  the  ceiling  lights  and  cause  operators  to  strain  their 
necks  upward.  (Findings  3. 5 [13]  &  [22]) 

•  The  current  location  of  the  printer  should  be  reconsidered.  (Finding 
3  •  5 [ 18 ] ) 

•  Mounting  the  computer  in  its  rack  and  removing  and  installing  its  top 
cover  are  excessively  time  consuming  procedures.  (Findings  3. 5 [26]  &  [27]) 

•  The  instability  of  the  M-880  truck,  which  houses  the  operations  shel¬ 
ter,  may  constitute  a  safety  hazard.  (Finding  4.1) 
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Resolved  or  Partially  Resolved  Issues 


•  The  DRS  user  interface  should  not  be  patterned  after  that  of  the  DCS 
for  the  sake  of  conformity.  It  was  decided  that  effective  design  should  take 
priority.  (Finding  3.1) 

•  The  probability  of  accidental  reinitialization  of  the  data  collection 
software  was  too  high.  These  problems  were  mostly  resolved  prior  to  the 
revalidation  test,  although  an  oversight  (concerning  the  F5  key)  was  discov¬ 
ered  during  that  test.  (Findings  3. 4 [4]  &  [31.1]) 

•  The  system  should  archive  data  on  a  regular  basis,  regardless  of 
traffic  density.  This  problem,  discovered  during  the  validation  test  was 
partially  resolved  prior  to  the  revalidation  test.  No  manual  archive  option 
is  provided;  it  should  be.  (Finding  3 . 4 [ 9 ] ) 

•  If  data  on  the  hard  disk  should  become  inaccessible,  the  TK50  tape 
would  have  no  backup  prior  to  input  into  the  DRS .  The  Army  is  relying  on  the 
redundancy  effected  by  the  presence  of  more  than  one  DCS  in  the  field,  some  or 
all  of  which  may  collect  partially  overlapping  sets  of  data.  (Finding 

3 . 4 [ 10 ] ) 

•  The  presentation  of  alert  messages  to  the  operator  was  unsatisfactory, 
creating  a  significant  chance  that  they  would  go  unnoticed.  This  shortcoming 
was  vastly  improved  prior  to  the  revalidation  test.  (Findings  3. 4 [24]  &  [25]) 
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Appendix 

Setup  and  Teardovn:  Detailed  Descriptions 


Table  4 

Detailed  Setup  Timeline  for  Revalidation  Test,  Day  3  (Table  2.  Expanded) 
Time/Elapsed  Time  (Minutes) :  Time/Elapsed  Time  (Minutes) : 

Operator  Activity _ Operator  Activity _ 


0812/000:  Start  setup.  Buttoned-up 

vehicle  with  attached  trailer  is 
already  in  place  at  predetermined 
trailer  location.  Two  operators,  A 
&  B,  are  present. 

A  &  B  disconnect  trailer  chains  & 
trailer  lights  cable  from  vehicle; 
lower  front  trailer  support;  re¬ 
move  trailer  from  hitch  (a  two- 
person  task) . 

A  moves  vehicle  straight  forward 
about  80  feet  to  its  predetermined 
operating  location. 

0813/001: 

A  lowers  shelter  steps;  unlocks  & 
opens  shelter  door. 

B  begins  to  deploy  power  cable  be¬ 
tween  trailer  &  shelter. 

0814/002: 

A  opens  curbside  storage  compartment 
on  side  of  shelter.  Begins  to 
drive  1st  electrical  grounding  rod 
near  shelter. 

A  continues  laying  out  power  cable. 
0815/003: 

A  finishes  setting  1st  grounding 
rod. 

B  finishes  deploying  power  cable. 
0816/004: 

A  drives  2nd  grounding  rod  near  gen¬ 
erator  trailer. 

B  begins  deploying  generator 
control-panel  cable  between 
trailer  &  shelter. 

0817/005: 

A  unstows  antenna  cables  from  shel¬ 
ter  storage  bin. 


B  finishes  connecting  generator 
control-panel  cable  between 
trailer  &  shelter. 

0818/006: 

A  unstows  GOES  antenna  from  inside 
shelter;  installs  on  roof  of 
shelter . 

B  enters  shelter;  unstows  operator 
chairs  &  miscellaneous  items. 

0819/007: 

A  finishes  installing  GOES  antenna. 

8  does  paperwork  on  system  note 
sheet. 

0820/008. 

A  opens  roadside  storage  cabinet  & 
antenna  mast  storage  tubes. 

B  completes  paperwork. 

0821/009: 

A  mounts  roadside  antenna  mast  as¬ 
sembly  at  rear  of  shelter. 

B  turns  on  computer;  unstows  monitor 
&  keyboard. 

0822/010: 

A  mounts  curbside  antenna  mast  as¬ 
sembly  at  rear  of  shelter. 

B  installs  keyboard. 

0823/011: 

A  unstows  various  antenna- related 
items  from  roadside  storage 
compartment . 

B  performs  miscellaneous  small 
tasks . 

0824/012: 

A  stakes  antenna  base  plate  to  earth 
beneath  roadside  antenna  mast. 
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Table  4.  continued 


B  removes  TK50  tapes  from  safe; 
waits  for  computer  to  warm  up. 

0825/013: 

A  lays  out  radius  line  for  position¬ 
ing  1st  roadside  guy  line  stake. 

B  exits  shelter  to  help  A  with  an¬ 
tenna  setup . 

0826/014: 

A  drives  1st  guy  line  stake  for 
roadside  antenna;  lays  out  radius 
line  for  locating  2nd  stake. 

B  obtains  stepladder  from  chase 
vehicle  (parked  beyond  generator 
trailer)  for  use  in  deploying 
curbside  antenna  whip. 

0827/015: 

A  drives  2nd  roadside  antenna  stake; 
lays  out  radius  line  for  locating 
3rd  stake. 

B  climbs  atop  shelter  &  installs 
transmit/receive  antenna  on  curb- 
side  antenna  mast. 

0828/016: 

A  drives  3rd  (last)  roadside  stake. 

B  installs  receive -only  antenna  on 
roadside  antenna  mast  &  dismounts 
shelter . 

0829/017: 

A  stakes  antenna  base  plate  to  earth 
beneath  curbside  antenna;  lays  out 
radius  line  for  1st  curbside  an¬ 
tenna  guy  line  stake. 

> \  B  emplaces  &  connects  test-coordina¬ 
tion  radio  antenna  atop  shelter 
for  local  base  communications. 

0830/018: 

A  drives  1st  curbside  antenna  guy 
line  stake. 

B  unwinds  antenna  cable  for  test- 
coordination  communications 
antenna . 

0831/019: 

A  lays  out  radius  line  for  2nd  curb- 
side  guy  line  stake. 

B  Enters  shelter. 


0832/020: 

A  drives  2nd  curbside  stake. 

B  prepares  for  computer  initializa¬ 
tion  (miscellaneous  tasks) . 

0833/021: 

A  lays  radius  line  for  3rd  curbside 
stake;  drives  3rd  (last)  stake. 

B  starts  computer  initialization  & 
waits  for  computer  to  run  self- 
tests . 

0834/022: 

A  connects  GOES  antenna  cable . 

B  waits. 

0835/023: 

A  begins  unstowing  (unwinding)  6 
antenna  guy  lines. 

B  waits. 

0836/024: 

A  continues  to  unwind  antenna  guy 
lines . 

B  waits  for  completion  of  computer 
self  tests. 

0837/025: 

A  continues  to  unwind  guy  lines . 

B  sets  wire  jumpers  in  preparation 
for  hard-wire  loop  test  of  modem 
channels . 

838/026: 

A  connects  antenna  cable  to  roadside 
antenna;  raises  antenna  slightly  & 
starts  to  place  1st  antenna  cable 
tie  wrap. 

B  continues  waiting  for  completion 
of  computer  self  tests. 

0839/027: 

A  completes  installation  of  1st 
roadside  antenna  cable  tie  wrap. 

B  initiates  AITG  test. 

0840/028: 

A  connects  antenna  cable  connector 
to  curbside  antenna. 

B  waits  for  completion  of  AITG  test. 
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0841/029: 

A  connects  antenna  cables  to  shelter 
junction  box  &  continues  with 
deployment  of  antenna  guy  lines. 

B  continues  to  wait  for  A1TG  test. 

0842/030: 

A  connects  guy  lines  to  curbside 
antenna;  continues  guy  line 
layout . 

B  continues  to  wait  for  AITG  test. 
0843/031: 

A  works  on  guy  lines. 

B  loads  &  activates  data  collection 
system. 

[At  this  time,  generator  power  to 
interior  of  shelter  is  lost,  al¬ 
though  generator  continues  to  run. 
Air  conditioning  &  lights  turn  off. 
Computer  equipment  continues  to 
operate  on  emergency  battery  power 
(UPS).] 

A  checks  outside  circuit  breaker  box 
&  reseats  generator  power  cable 
connector.  [Negative  results.] 

0844/032: 

[Operations  halted  for  approximately 
1  minute  for  consultation  not  re¬ 
lated  to  power  loss:  Because  TAC- 
FIRE  system  is  not  completely  func¬ 
tional,  a  change  in  hard-wire  layout 
to  TACFIRE  is  planned. ] 

0845/033: 

A  &  B  readdress  power  loss  problem. 

A  attempts  to  open  high  voltage 
panel  cover  inside  shelter,  but 
reports  that  latch  key  will  not 
work.  [Apparently,  key  unlocks 
latch,  but  latch  sticks;  key  can¬ 
not  be  used  as  a  handle  to  pull 
out  latch- -the  normal  procedure.] 

0846/034 : 

A  wrestles  with  the  lock. 

B  waits. 

0847/035: 

A  looks  for  a  screwdriver. 


B  waits. 

0848/036: 

A  pries  open  late-  with  screwdriver; 
examines  switches  [None 
tripped. ] 

B  waits. 

0849/037: 

A  closes  &  locks  high  voltage  panel 
cover. 

B  checks  interior  breaker  box  at 
lower  front  curbside.  [CB-14  is 
tripped.  See  Finding  2.4(1)&(7).] 

0850/038: 

[Operators  report  that  this  particu¬ 
lar  problem  had  never  happened 

before . ) 

A  waits . 

B  resets  CB-14.  [Power  is  re¬ 
stored.]  Continues  modem  channel 
testing  procedures. 

0851/039: 

A  &  B  prepare  for  continuation  of 
operations:  pickup  tools,  etc. 

0852/040: 

A  retrieves  &  stows  antenna  base 
plates  [used  in  current  applica¬ 
tion  solely  as  retainers  for  guy 
lines  during  guy  line  layout] ; 
drives  tie-off  stake  for  field 
wire  (WD-1)  under  curbside  rear 
junction  box. 

B  continues  channel  testing 
procedures . 

0853/041: 

A  rewinds  &  stows  radius  line. 

B  continues  channel  tests. 

0854/042: 

A  begins  laying  out  guy  lines  for 
curbside  antenna. 

B  continues  channel  tests. 

0855/043: 

A  &  B  discuss  layout  of  field  wire 
to  TACFIRE  vehicles . 
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0856/044: 

A  suspends  work  on  guy  lines;  begins 
laying  field  wire. 

B  continues  with  channel  tests. 

0857/045: 

A  strips  insulation  from  wire  for 
connecting  to  1st  TACFIRE  vehicle. 

B  continues  channel  testing. 

0858/046: 

A  begins  making  connection  at  1st 
vehicle . 

B  continues  channel  testing. 

0859/047: 

A  continues  connecting  at  1st 
vehicle . 

B  continues  channel  testing. 

0900/048: 

A  completes  connection  at  1st 
vehicle . 

B  continues  channel  testing. 

0901/049: 

A  strips  insulation  from  other  end 
of  1st  vehicle  wire  for  connecting 
at  C3I2  shelter. 

B  continues  channel  testing. 

0902/050: 

A  connects  wire  from  1st  vehicle  to 
shelter  junction  box  &  tie-off 
stake . 

B  waits  for  last  channel  test  (chan¬ 
nel  8)  to  end. 

0903/051: 

A  writes  ID  label  for  1st  vehicle 
wire;  attaches  it  at  C3I2  shelter 
end. 

B  waits  for  last  channel  test  (chan¬ 
nel  8)  to  end. 

0904/052: 

A  starts  wire  layout  to  2nd  TACFIRE 
vehicle.  Strips  wire  at  vehicle 
end. 

B  performs  "configure  channels" 
procedure  &  starts  "runtime  sys¬ 
tem"  (data  collection  process). 


0905/053: 

A  begins  connecting  wire  to  2nd 
vehicle . 

B  prepares  to  print  out  current  con¬ 
figuration  information. 

0906/054: 

A  continues  connecting  to  2nd 
vehicle . 

B  begins  print  of  configuration  in¬ 
formation. 

0907/055: 

A  continues  connecting  to  2nd 
vehicle . 

B  completes  print  of  configuration 
information. 

0908/056: 

A  continues  connecting  to  2nd 
vehicle . 

B  begins  to  check  for  software  alert 
messages . 

0909/057: 

A  completes  connection  at  2nd 
vehicle . 

B  finishes  checking  alert  informa¬ 
tion  [no  negative  alerts  present] . 

0910/058: 

A  strips  2nd  vehicle  wire  at  C3I2 
shelter  end;  connects  to  shelter 
junction  box  &  tie-off  stake. 

B  waits,  observes  monitor.  Messages 
begin  to  come  in. 

0911/059: 

A  labels  wire  from  2nd  vehicle  at 
shelter  end. 

B  observes  monitor. 

0912/060: 

A  starts  deploying  wire  to  3rd  TAC¬ 
FIRE  vehicle. 

B  comes  outside  of  shelter  to 
assist . 
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0913/061: 

A  &  B  finish  laying  wire  to  3rd 
vehicle . 

0914/062: 

A  making  wire  connection  to  3rd 
vehicle . 

B  looks  for  wire  cutters  [which  A 
has]  . 

0915/063: 

A  completes  wire  connection  to  3rd 
vehicle;  makes  ID  label  for  C3I2 
shelter  end. 

B  uses  jackknife  to  strip  3rd  wire 
for  connection  to  shelter. 

0916/064: 

A  begins  to  lay  out  wire  to  4th 
vehicle . 

B  continues  attempting  to  strip  3rd 
wire  with  jackknife  blade. 

0917/065: 

A  continues  laying  wire  for  4th 
vehicle . 

B  still  working  to  strip  3rd  wire. 

0918/066: 

A  begins  making  connection  to  4th 
vehicle . 

B  completes  stripping  of  3rd  wire. 

0919/067: 

A  continues  connecting  to  4th 
vehicle . 

B  connects  3rd  wire  to  shelter  & 
attaches  ID  label. 

0920/068: 

A  completes  connection  at  4th 
vehicle . 

B  secures  3rd  wire  to  tie-off  stake; 
begins  to  strip  shelter  end  of  4th 
wire  with  knife. 

0921/069: 

A  gives  wire  cutters  to  B. 

B  strips  wire  for  5th  vehicle, 

thinking  it  to  be  shelter  end  for 
4th  vehicle . 


0922/070: 

A  labels  4th  vehicle  wire  at  shelter 
end. 

B  continues  to  strip  wire  for  5th 
vehicle . 

0923/071: 

A  starts  to  connect  4th  wire  to 
shelter;  discovers  that  ends  are 
not  stripped;  informs  B.  Begins 
to  lay  out  wire  for  5th  (&  last) 
vehicle;  discovers  patched  break 
in  wire;  cuts  off  at  break  & 
starts  over  with  new  wire. 

B  begins  to  strip  shelter  end  of  4th 
wire . 

0924/072: 

A  continues  laying  out  wire  for  5th 
vehicle . 

B  completes  stripping  wires  for  4th 
vehicle;  gives  cutters  to  A. 

0925/073: 

A  strips  5th  vehicle  wire  at  vehicle 
end;  gives  cutters  to  B;  continues 
laying  wire  to  5th  vehicle. 

B  begins  connecting  4th  vehicle  wire 
to  shelter . 

0926/074: 

A  starts  connection  at  5th  vehicle. 

B  finishes  connecting  4th  wire  to 
shelter  &  tie-off  stake. 

0927/075: 

A  continues  working  on  connection  at 
5th  vehicle. 

B  begins  to  strip  5th  vehicle  wire 
at  C3I2  end. 

0928/076: 

A  finishes  connecting  wire  at  5th 
vehicle . 

B  continues  to  strip  5th  vehicle 
wire  at  shelter. 

0929/077: 

A  makes  label  for  5th  vehicle  wire. 

B  completes  stripping. 


A-  5 


Table  4.  continued 


0930/078: 

A  stores  leftover  wire. 

B  connects  5th  vehicle  wire  to 
shelter . 

0931/079: 

A  continues  work  on  antenna  mast  guy 
lines;  begins  to  connect  remaining 
lines  to  stakes. 

B  ties  off  5th  vehicle  wire  at  re¬ 
taining  stake. 

0932/080: 

A  raises  curbside  antenna;  tie -wraps 
antenna  cable  to  mast  as  mast  is 
being  raised. 

B  plays  out  guy  line  as  curbside 
antenna  is  raised  by  A  &  connects 
to  stake. 

0933/081: 

A  attaches  2  of  3  guy  lines  to  curb- 
side  antenna  midsection  collar. 

B  lays  out  guy  lines  &  connects  to 
stakes . 

0934/082: 

A  continues  to  raise  curbside  an¬ 
tenna  &  tie -wrap  antenna  cable  (8 
tie-wraps  altogether).  Attaches 
remaining  guy  lines  to  antenna 
mast  (3  at  midsection  collar  &  3 
at  top  plate) . 

B  assists  by  playing  out  guy  lines 
as  antenna  is  raised. 

0935/083: 

A  &  B  continue  raising  curbside 
antenna . 

0936/084: 

A  &  B  continue  raising  curbside 
antenna . 

0937/085: 

A  &  B  complete  raising  curbside 
antenna;  adjust  guy  line  tension 
to  straighten  antenna.  Begin 
erection  of  roadside  antenna. 


A  tie -wraps  curbside  antenna  cable 
to  antenna  mast;  attaches  guy  line 
to  incorrect  collar. 

B  plays  out  guy  lines . 

0938/086: 

A  discovers  attachment  of  guy  line 
to  incorrect  mast  collar;  lowers 
mast  section;  reattaches  guy  line 
to  correct  collar. 

B  waits. 

0939/087: 

A  &  B  continue  erecting  roadside 
antenna  mast. 

A  attaches  3  guy  lines  to  midsection 
mast  collar. 

0940/088: 

A  &  B  continue  erecting  roadside 
antenna  mast. 

0941/089: 

A  &  B  continue  erecting  roadside 
antenna  mast. 

0942/090: 

A  &  B  continue  erecting  roadside 
antenna  mast. 

0943/091: 

A  6c  B  complete  erecting  mast  &  begin 
adjusting  guy  lines  to  straighten 
antenna . 

0944/092: 

A  &  B  finish  deployment  of  roadside 
antenna . 

A  returns  stepladder  to  chase  vehi¬ 
cle  6c  stows  it  inside;  closes 
exterior  shelter  storage  compart¬ 
ments  &  enters  shelter. 

B  enters  shelter. 

0945/093: 

A  stows  wire  cutters  &  extra  tie 
wraps  in  tool  chest. 

B  enters  time  in  mission  log. 
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Table  5 


Detailed  Teardown  Timeline  for  Revalidation  Test,  Day  3  (Table  3,  Expanded) 


Time/Elapsed  Time  (Minutes):  Time/Elapsed  Time  (Minutes): 

Operator  Activity _ Operator  Activity _ 


1608/000:  Start  shutdown.  DCS 

software  already  exited. 

A  retrieves  tape  labeling  materials 
from  storage. 

B  removes  analogue  and  TK50  tapes 
from  recorders. 

1609/001: 

A  takes  tapes  from  B;  begins  to  pre¬ 
pare  tape  labels . 

B  retrieves  computer  panel  key. 

1610/002: 

A  continues  to  prepare  labels. 

B  uses  computer  panel  key  to  enable 
panel  buttons;  turns  off  computer. 

1611/003: 

A  affixes  label  to  analogue  tape. 

B  makes  entries  in  mission  log. 

1612/004: 

A  affixes  label  to  TK50  tape;  exits 
shelter . 

B  continues  to  write  in  mission  log. 

1613/005: 

A  disconnects  field  wire  (WD-1)  from 
shelter  junction  box;  removes  GOES 
antenna  from  shelter  roof;  stows 
GOES  antenna  in  shelter. 

B  turns  off  air  conditioner;  secures 
tapes  in  shelter  safe;  places  key¬ 
board  in  storage  drawer  &  secures 
monitor  with  bungee  cord. 

1614/006: 

A  disconnects  generator  control - 
panel  cable  from  shelter;  discon¬ 
nects  shelter  ground  rod  cable. 

B  secures  chairs  with  bungee  cords; 
exits  shelter;  disconnects  power 
cable  from  shelter. 

1615/007: 

A  closes  shelter  junction  box 
hatches  on  curbside. 


B  detaches  &  stows  shelter  ground 
rod  cable. 

1616/008: 

A  begins  to  lower  roadside  antenna. 

B  begins  to  wind  up  roadside  antenna 
guy  lines. 

1617/009: 

A  continues  to  lower  roadside  an¬ 
tenna;  removes  guy- line  clips  from 
upper  antenna  mast  collar;  cuts 
antenna  cable  tie-wraps. 

B  continues  to  wind  guy  lines . 

1618/010: 

A  continues  taking  down  roadside 
antenna;  removes  guy- line  clips 
from  lower  antenna  mart  collar. 

B  continues  to  wind  guy  lines. 

1619/011: 

A  completes  roadside  antenna  take¬ 
down. 

B  continues  winding  guy  lines. 

1620/012: 

A  6t  B  continue  winding  guy  lines  for 
roadside  antenna. 

1621/013: 

A  winds  up  roadside  antenna  cable. 

B  continues  winding  guy  lines. 

1622/014: 

A  stows  antenna  cable. 

B  winds  guy  lines. 

1623/015: 

A  takes  down  &  stows  test-coordina¬ 
tion  radio  antenna  &  cable;  re¬ 
moves  roadside  antenna  mast  from 
rear  of  shelter;  places  it  in 
storage  tube. 

B  completes  winding  up  of  guy  lines 
for  roadside  antenna;  gets  step- 
ladder  from  chase  vehicle. 
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1624/016: 

A  stows  roadside  antenna  whip  in 
storage  tube. 

B  begins  takedown  of  curbside  anten¬ 
na;  disconnects  upper  guy  lines; 
cuts  antenna  cable  tie -wraps. 

1625/017: 

A  stows  guy  lines  from  roadside  an¬ 
tenna  in  utility  bag;  pulls  road¬ 
side  antenna  stakes  &  stows  in 
utility  bag. 

B  continues  to  take  down  curbside 
antenna . 

1626/018: 

A  begins  to  wind  up  guy  lines  for 
curbside  antenna. 

B  removes  lower  set  of  guy  lines 
from  curbside  antenna  mast. 

1627/019: 

A  continues  to  wind  guy  lines. 

B  removes  whip  antenna  from  curbside 
antenna  mast;  removes  mast. 

1628/020: 

A  winds  guy  lines. 

B  stows  curbside  antenna  mast  in 
storage  tube. 

1629/021: 

A  winds  guy  lines. 

B  stows  curbside  antenna  whip  sec¬ 
tions  in  storage  tube. 

1630/022: 

A  stows  storage  bag  in  roadside 
compartment;  begins  to  pull  curb- 
side  antenna  guy  line  stakes. 

B  winds  guy  lines. 

1631/022: 

A  finishes  pulling  guy  line  stakes; 
stows  them  away. 

B  winds  guy  lines. 

1632/023: 

A  starts  to  take  in  field  wire  from 
TACFIRE  vehicles. 

B  finishes  winding  up  curbside  an¬ 
tenna  guy  lines. 


1633/024: 

A  continues  taking  in  field  wire . 

B  winds  up  curbside  antenna  cable; 
stows  in  curbside  compartment. 

1634/025: 

A  &  B  take  in  field  wire. 

1635/026: 

A  &  B  take  in  field  wire. 

1636/027: 

A  &  B  take  in  field  wire. 

1637/028: 

A  &  B  take  in  field  wire. 

1638/029: 

A  &  B  take  in  field  wire. 

1639/030: 

A  &  B  take  in  field  wire. 

1640/031: 

A  &  B  take  in  field  wire. 

1641/032: 

A  &  B  take  in  field  wire. 

1642/033: 

A  &  B  take  in  field  wire. 

1643/034: 

A  &  B  take  in  field  wire. 

1644/035: 

A  &  B  take  in  field  wire. 

1645/036: 

A  &  B  take  in  field  wire. 

1646/037: 

A  &  B  take  in  field  wire. 

1647/038: 

A  stows  second  storage  bag;  locks 
roadside  compartment  padlocks. 

B  winds  field  wire. 

1648/039: 

A  pulls  shelter  ground  rod  &  stows 
in  curbside  compartment;  pulls 
generator  trailer  ground  rod. 
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Table  5.  continued 


B  winds  field  wire. 

1649/040: 

A  stows  trailer  ground  rod  &  ground 
rod  puller  in  shelter  curbside 
compartment;  locks  compartment 
padlocks . 

B  carries  stepladder  to  chase 
vehicle . 

1650/041: 

A  removes  steps  from  rear  of  shel¬ 
ter;  closes,  but  does  not  lock, 
shelter  door. 

B  winds  up  generator  control -panel 
cable . 

1651/042: 

A  assists  B  in  winding-up  power 
cable. 

1651/043: 

A  carries  WD-1  spool  &  shelter  steps 
as  far  as  generator  trailer;  helps 
B  wind  &  stow  power  cable  at  gen¬ 
erator  trailer. 

B  finishes  stowing  power  cable  with 
A's  assistance. 


1652/044: 

A  stows  shelter  steps  in  generator 
trailer. 

B  stows  WD-1  spool  &  stepladder  in 
chase  vehicle. 

1653/045: 

A  backs  up  shelter  vehicle  to 
trailer . 

B  stands  by. 

1654/046: 

A  &  B  connect  trailer  to  vehicle . 
1655/047: 

A  locks  antenna  storage  tube 
padlocks . 

B  retrieves  trash  from  shelter. 
1656/048: 

A  stows  used  WD-1  wire  in  shelter. 
B  s  tands  by . 

1657/049:  Teardown  completed. 

A  secures  shelter  door. 

B  stands  by. 
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